Discussions

News: Bitter EJB ships

  1. Bitter EJB ships (21 messages)

    In Bitter EJB, Bruce Tate and his co-authors continue the entertaining and engaging writing style of relating true-life adventure sport experiences to antipattern themes established in Bruce's first book, the best selling Bitter Java.

    This more advanced book explores antipatterns, or common traps, within the context of EJB technology.

    EJB is experiencing the mixture of practical success and controversy that accompanies a new and quickly-changing framework. Bitter EJB takes the swirling EJB controversies head-on. It offers a practical approach to design: how to become a better programmer by studying problems and solutions to the most important problems surrounding the technology.

    The flip side of design patterns, antipatterns, are a fun and interesting way to take EJB expertise to the next level. The book covers many different aspects of EJB, from transactions to persistence to messaging, as well as performance and testing.

    Bitter EJB will teach programmers to do the following:

    Identify EJB persistence strategies
    Choose Entity bean alternatives
    Use EJB message driven beans
    Know when to apply or avoid stateful session beans
    Create efficient build strategies with XDoclet, Ant and JUnit
    Automate performance tuning

    Manning's Bitter EJB area

    Threaded Messages (21)

  2. Bitter EJB ships[ Go to top ]

    EJB is experiencing the mixture of practical success and controversy

    > that accompanies a new and quickly-changing framework.

    So let's start ;) Can a framework that is around since... mid-1998 still be considered a new technology? Not in my opinion. EJBs are not new, but they are still not mature after 5 years. EJBs are by far the less stable Java technology around...

    > Bitter EJB takes the swirling EJB controversies head-on. It offers a
    > practical approach to design: how to become a better programmer by
    > studying problems and solutions to the most important problems
    > surrounding the technology.

    Sorry, but this is really symptomatic. Technology is there to help us meet the customer/user requirements. Where do we go if we need "solutions to the most important problems surrounding the technology"?

    JDO seems to be catching the attention again, as an alternative to entity beans. In these JavaOne days, it is good to remind that JDO was one of the new technologies presented at... JavaOne 2000, three years ago. SUN has put too much efforts on EJBs, slowing down the whole Java evolution. Hopefully, the open source movement was around to bring back pragmatism to Java developers thanks to frameworks like Struts, Axis, Hibernate, etc.

    Anyway, good luck with your book.

    Bertrand Fontaine
    INSPIRE IT - www.inspireit.biz
    JavaShelf.com: Your Java bookstore on the Web!
  3. Um, having a bad day?[ Go to top ]

    Thanks for your feedback. Keep in mind that you're reading a press release.

    I generally try to stay on the optimistic side of things, but this post is symptomatic of the ready-fire-aim posting style that is killing on-line communities everywhere. Instead of taking pot shots at a press release, how about actually reading some of the book? We've had nearly all of the early chapters for review on TSS for months now, and our feedback was overwhelmingly positive. We've also released some free chapters at www.manning.com/tate2. Some of the brightest authors in the industry have provided feedback for this book, and provided inteligent feedback that we feel helped us to write a better book.

    If you want to take some shots, let me give you some better amunition.

    1) It's not like most books. You won't find the dry, safe style that most software books have adopted these days. The style may well turn off some developers. (Others will celebrate it as interesting and different.)

    2) You won't find another collection of design patterns, that in many cases are workarounds to antequated architectures. If you're looking for a book that blindly props up the state of the art, you won't like this one. (Instead, you'll see us take on some of the problems, like EJB persistence, yes, head-on. Not many have done so in this format.)

    In short, if you're looking for the status quo, don't buy Bitter EJB. However, there are some things that we feel that we do fairly well.

    * We acknowledge the niches where EJB fit.
    * We acknowledge that EJB are not for everyone, and in fact, have major areas like persistence that need revision. Few other EJB books have acknowledged fundamental EJB weaknesses, like the entity model.
    * This team of authors includes four authors who are from small companies or are independent consultants, so we're not married to the party lines that you're likely to find in the open source communities or major Java companies.
    * The book is well written. Like most Manning books, our editing team is outstanding.

    If you want to publicly shred the book after spending 10 bucks on an e-book or at least reading the free sample chapters at www.manning.com/tate2, be my guest. I'll likely get your feedback into the next Bitter book. But taking pot shots at a year of effort without doing any research at all is probably not going to sit well with the authors and TSS reviewers who worked so hard to put this quality project together.
  4. So let's start ;) Can a framework that is around since... mid-1998 still be considered a new technology?



    Of course, EJB and Java are evolving rapidly. WebSphere just started supporting EJB 2.0 with their 5.0 release, and the last major release of EJB contained MDB and a complete overhaul of CMP, which are both centeral themes in the book. Considering that it takes about a year to get a book out, and that it takes some time to let customers use a product before you can publish about their experiences, I'd say that the book is pretty timely.



    > Sorry, but this is really symptomatic. Technology is there to help us meet the customer/user requirements. Where do we go if we need "solutions to the most important problems surrounding the technology"?

    Few of us ever actually choose our technologies. Most of us have to play the hand that we're dealt. Against that backdrop, it's important to have a bag of tools and tricks that solves, yes, problems surrounding a technology. Case in point: given EJB, how do you do persistence? Find me an EJB book that speaks out against EJB entities. They are few and far between, though many of us have come to the conclusion that EJB persistence may be fatally flawed.


     
    > JDO seems to be catching the attention again, as an alternative to entity beans. In these JavaOne days, it is good to remind that JDO was one of the new technologies presented at... JavaOne 2000, three years ago.

    Cute. You fail to point out that the JDO 1.0 spec was accepted in April 2002. That's just over a year old. (The original JSR, 00012, pointing out the sentiments of the community, is in fact nearly 5 years old, but the *standard* is just over a year old.)

    >
    > Anyway, good luck with your book.
    >
    > Bertrand Fontaine

    Thanks. We put a whole lot of hard work into it, and those who have written a technical book know that you don't do it for the money. I'd be interested to hear your comments once you've read a little of the book. Judging strictly from your early comments, it's not what you think. I'd also like to hear from others in the TSS community that have read it or reviewed it.

    Take care.
    - Bruce Tate
  5. Bitter EJB ships[ Go to top ]

    I just want to say that this book should be required reading for anyone even thinking about using EJB. I was only able to read a few of the sample draft chapters but they were enough to change my thinking about EJB. Before I always put down EJB (in favor of JDO) but after reading a portion of this book I now realize that EJB is good for some situations and not good for others. Identifying which is which is the challenge. So many architectures are built upon EJB when they really don't need to be, and could be written quicker/smaller/lighter/faster/cheaper with plain ole java objects, JDO (or even Hibernate) and Tomcat. The sample chapters I read were really interesting and enteraining, unlike the majority of computer books out there. The author really has a great writing style. Congrats on producing such an excellent resource, I look forward to reading the finished book!

    Michael
  6. Bitter EJB ships[ Go to top ]

    Thanks for your kind comments.

    Re. persistence, I'm also a big Hibernate fan. It is actually well-integrated with EJB. Hibernate with a session facade is an interesting choice.
  7. Bitter EJB ships[ Go to top ]

    I think that the hard work you have put in your book explains your over-reaction about my comment. You should re-read yourself, you would realize that your reply is actually in the "ready-fire-aim posting style that is killing on-line communities everywhere". Is it really forbidden to underline the fact that EJBs are not so new after 5 years? Or that technology is there to help us meet our customer requirements, i.e. be part of the solution and not of the problem? I don't think so. Anyway, if you are feeling offended, all my apologies.

    <Bruce>
    Few of us ever actually choose our technologies.
    </Bruce>

    This is a major problem. I am sure that like me, you have around you numerous Java developers who are convinced that EJBs are not the way to go for their specific problem but who are afraid of discussing about it with their boss or client. Some parts of your book may help Java developers in that situation to "feel stronger", and this is a good thing.

    <Bruce>
    Cute. You fail to point out that the JDO 1.0 spec was accepted in April 2002. That's just over a year old. (The original JSR, 00012, pointing out the sentiments of the community, is in fact nearly 5 years old, but the *standard* is just over a year old.)
    </Bruce>

    This is my whole point, actually. JDO was already more than a vague idea in JavaOne 2000. I remember that Versant was particularly proud to be first with their 'Judo' implementation. Two years more to finalize a 1.0 spec is not really what I call 'Internet time'. I think that the potential competition of JDO with some parts of EJB explain why it took so much time, but this is only a guess.

    This being said, I will have to investigate why "Bitter EJB" is not yet listed on JavaShelf.com. ;)

    Bertrand
  8. Bitter EJB ships[ Go to top ]

    I hope all this hair-splitting about "newness," etc. doesn't detract from the core message. New or not, EJB is still widely misunderstood, by advocates and detractors alike. A technology that's still in the throes of its first big backlash definitely deserves the kind of sane, experienced, unbiased treatment I see in "Bitter EJB." I got a copy early last week, and I'm going through the chapters I wasn't able to preview here on the site. It's a very good book.

    I'm one of those who usually bash EJB at every opportunity, but even I have to admit that's not entirely fair. I overdo it a little out of frustration with the way so many teams have unquestioningly accepted EJBs, even while being overwhelmed by their problems. Bitter EJB is more disciplined. Although there are many discussions of pitfalls and weaknesses, the authors are honest about the strengths that EJB-based architectures can have. I'm glad this book is around for my customers to read.
  9. Thanks for the response[ Go to top ]

    I have tremendous respect for you, and your opinion matters to this team. I think you've captured the spirit of what we're trying to do very well.

    I enjoyed your point about the first big backlash. Most technologies must undergo such a backlash before being more broadly accepted. I think that the book "Crossing the Chasm" spells out this pattern very well. In some ways, negative usage patterns (I call them antipatterns) can accentuate the backlash, leading to perhaps unfair criticism. In other places, the framework contributes to the backlash. In Bitter EJB, we try to spell out each one.

    Thanks again for your kind response.
  10. Bitter EJB ships[ Go to top ]

    "I'm one of those who usually bash EJB at every opportunity, but even I have to admit that's not entirely fair."

    Gracious to admit that you aren't always "fair", but I seem to deal with the opposite most of the time. The backlash against EJB has become so strong that most developers I run across assume that you shouldn't touch EJB -- even session beans -- with a 10 foot pole. I often have to ask how they accomplish many of the capabilities that EJB bring to the table, and they are often unable to answer these criticisms.

    When I first looked through some of the Bitter EJB material, I had assumed that it was going to be "ammunition" for these developers to continue using. However, after reading several of the chapters, I was actually relieved to see that the authors were actually very positive about using the technology "the right way."

    Most importantly, the materials seemed to address the real problems that you are going to encounter when building application architectures and described the various approaches you could take. EJB isn't going to be the right answer in all -- many? -- cases, but when you don't use the services they provide, you better have another answer. (E.g., persistence is just one piece of the puzzle.)

    Russ
  11. Bitter EJB ships[ Go to top ]


    > When I first looked through some of the Bitter EJB material,
    > I had assumed that it was going to be "ammunition" for these
    > developers to continue using. However, after reading several
    > of the chapters, I was actually relieved to see that the authors
    > were actually very positive about using the technology
    > "the right way."
    >

    Thanks for noticing our positive attitude. It's good to know that it shined through as that was our intent. Just as "Bitter Java" wasn't intended to bash Java, "Bitter EJB" isn't intended to bash EJB. Indeed, both books are intended to help you deliver software of value by using tools to your advantage. Sometimes that means deliberately and pragmatically choosing not to pick up a certain tool.
     
    When Bruce asked me if I'd write the chapter on stateful session beans, my initial reaction was that it would be quite short. Indeed, my first (conditioned) thought was that using stateful session beans was _the_ antipattern. "Stateful session beans? Everybody knows those are evil!" It would have been all too easy to just add more fuel to the bonfire.

    And then I started considering all the options for managing session state, assuming that my application benefits from such state. The result is a 30-page chapter, the centerpiece of which is an antipattern related to the golden hammers of managing session state. That is, the primary antipattern isn't bashing the use of stateful session beans. Rather, the antipattern is using the same tool universally to store session state.

    I can avoid swinging a golden hammer by first considering the tools available to me, and then making a decision based on the needs of our application. In the chapter, I go through that decision-making process by examining several session state tools including storing state on the client, storing state in the server using HttpSession or stateful session beans, and storing state in the database. For each tool I enumerate its advantages, disadvantages, and opportunities when it's best used. Then I apply what I've learned to choose the best tool for managing session state in an example application.

    Context matters. "Bitter EJB" offers guideposts to help you make the best decision based on your context.

    Mike Clark
  12. Good insight.[ Go to top ]

    Nice post. I think that you've described two prevailing attitudes well:

    1) Some people say "I don't like EJB" and mean "I don't like entity beans." How can you blame so many people for trying entity beans and giving up on EJB all together? After all, a huge portion of the spec is dedicated to persistence, and a whole lot of EJB failure can be traced back to that technology.

    2) Some people say "The EJB are too complex," but they mean "EJB are too complex for the simple problems that I am trying to solve."

    I believe that those passionate arguments are difficult to handle, because there's a whole lot of truth in both statements. Your point is that EJB session and MDB beans do handle distributed transactions very well, and do provide a nice abstraction for many of the core container services.

    I'd be currious to hear from some of our reviewers on this topic.
  13. Good insight.[ Go to top ]

    Bruce, since that post I have had a chance to purchase and read through the entire book. Here are some more of my thoughts:

    * Overall, I am very pleased with it, and I think it should be required reading for any "enterprise Java" developer.
    * I was a bit disappointed in the depth of some of the solutions, but this book is not meant to be book for experienced Java architects, so I can't fault you all for that.
    * I wish you all had put a bit more theory at the beginning like Bitter Java had. I think that many of the people who are "bitter" towards EJB don't always understand the rationale for EJB, so they tend to dismiss it. When looking for anti-patterns, you should first understand the motivation for why something may have been built a certain way.

    Let me know if you need any authors for "Bitter Project Management", I could pontificate on that one for hours! ;)

    Russ
  14. EJB backround[ Go to top ]

    I wish you all had put a bit more theory at the beginning like Bitter Java had.

    > I think that many of the people who are "bitter" towards EJB don't always
    > understand the rationale for EJB, so they tend to dismiss it. When looking for
    > anti-patterns, you should first understand the motivation for why something may
    > have been built a certain way.

    Yes -- this was a point of debate during the writing process. We made a couple attempts to inject more history into the book, but most of the historical sections ended up delving into CORBA details that most EJB users really aren't interested in.

    This has been a problem with EJB all along -- we have all misapplied it in varying different ways and to varying different degrees. However, the EJB spec has started to migrate in the directions of our misapplication. So, these days, the beast that is EJB 2.1 is quite different than the original specification, and has some considerably different design goals.

    In the end, we decided that we'd stick with a practical analysis of common antipatterns rather than delve into the motivations behind the spec. We were afraid of losing people in the details of distributed computing history. It is my hope that we've struck a happy medium by discussing in chapter 2 and via the antipattern solutions which applications and tasks are suitable for EJB, thus giving examples of valid uses of EJB, and demonstrating by example where EJB fits into the J2EE world.

    -Patrick
  15. Thanks, Patrick.[ Go to top ]

    I've never gotten the opportunity to publicly thank you. This was a huge project for a VP at a small company to take on...and you came through with flying colors. Your contributions were incredible.
  16. Interesting suggestions.[ Go to top ]

    Great minds think alike. I originally started the book with some supporting theory, just as you suggested. And pretty much all of the reviewers asked me to take it out. The motivation was this: one of the dangers of writing a book is that if you don't dive in quickly enough, then you risk losing a large portion of your intended audience. Since we worked to make something that you can read cover to cover, this would have been alarming.

    So...we moved Bitter Cost up from chapter 6 to chapter 2, and added some of the motivation for choosing EJB...we struck a chapter on EJB 101, moved our tutorial chapter back to the end of the book, struck the chapters on antipatterns (actually, included chapter 1 of Bitter Java in the back of the book, and nearly all of the reviewers were pleased, while we also acknowledged that it was somewhat of a compromise.

    Hope this discussion adds insight into the final product.

    Re. depth of the discussions, you nailed it very well. We didn't want to write a phone book (nobody reads those), so we could either do depth or breadth. We settled for breadth, and added considerable depth around a few important topics: how do you do persistence, how do you tune this beast, how do you make the build process manageable.

    Re. bitter project maangement, I think that would make an attractive book. We briefly toyed with a Bitter XP. I may well return to something like that, but broader.

    I share your likes and dislikes of the book. Overall, as you say, we are also pleased.
  17. Bitter EJB ships[ Go to top ]

    Gracious to admit that you aren't always "fair", but I seem to deal with the opposite most of the time. The backlash against EJB has become so strong that most developers I run across assume that you shouldn't touch EJB -- even session beans -- with a 10 foot pole. I often have to ask how they accomplish many of the capabilities that EJB bring to the table, and they are often unable to answer these criticisms.


    Exactly! This works for both session and entity beans. Session beans: How do you get clustering and transparent failover? RMI? Yeah right (maybe a vendor-specific impl). Jini? Good luck finding affordable, competent developers with Jini experience. Web services? Possibly, but that brings a whole new bag of headaches (mapping mismatches, performance problems, etc.). This still leaves us with pooling and thread management. I was talking to a coworker the other day and I commented on how most EJB docs don't really emphasize that EJBs handle threading by allowing only a single thread to access a bean at a time. I then realized that the truth is that your average application developer doesn't think about threading. This is who EJB caters to and it does a pretty damned good job of it.

    Entity beans: can we all quit crapping on them for 10 seconds? Sure they had a rough start. Fine grained remote interfaces, distributed domain objects--what were we thinking? This does not mean however that they are the hell spawn. I'm afraid a lot of developers here these criticism and think they should just stick with JDBC. No! No, no, no, no, no! For anything but the most basic database-accessing web application, this is a nightmare. Performance tuning custom JDBC implementations results in tons of complicated, duplicated code, not to mention that type checking is thrown right out the window on top of it. Let the container handle caching, pre/lazy loading, relationships, etc. If you can't convince the higher-ups that JDO, Hibernate, etc. is the way to go, entity beans make a fine alternative. I'm actually using them right now, and with the help of a few good design patterns, I have a real OO domain layer with polymorphism, reentrance, etc. Plus, I can test my business logic outside of the container.
  18. Not an entity bean fan.[ Go to top ]

    That's what makes a four-person team of authors fun. Different opinions. As for EJB, I agree whole heartedly about session beans. They greatly simplify the clustering and pooling that you've got to build for scalability. You can make a similar argument for building JMS consumers with MDB.

    But to me, about the best thing that you can say for entity beans is that they suck less than they used to. It's still a coarse-grained model for a fine-grained problem. They're still cumbersome. They lack transparency. As a persistence model, the best reason to use entity beans is that your boss says that you have to.

    Take care, Bob. I enjoyed writing this book with you.
  19. Bitter EJB ships[ Go to top ]

    This is a great book. Nice balance in trems of ctriticism and advocacy.

    In chapter 3 you discuss the Session Facade pattern. This is a frequently used pattern and it seems like it is universally accepted. Looking at your example in the book, I'm wondering why you couldn't place the method from the Session Facade on the Entity Bean itself? Why create an additional EJB? Could you not call a getBookingData() method on the Booking EJB that in turn would assemble a DataTransferObject and returning it? Am I missing something here?
  20. Good question.[ Go to top ]

    The facade can take many forms. I would hesitate to wrap the coarse-grained methods for data access into my entity model, because it would confuse the api. You'd then have a cumbersome mix of course and fine grained access methods, which would be prone to abuse and confusion.

    Of course, the facade can take many forms. It need not be a session bean. It could be a message driven bean, or something customized. In a book about ejb, and one that doesn't favor entity beans, it makes sense to put the facade in an MDB or a stateless session bean.

    For scalability, a facade for a persistent model sould be stateless, poolable, secure, transactional and distributed.

    I hope this helps.
  21. Good question - good answer.[ Go to top ]

    Bruce,

    I see your point and I don't disagree with you. I guess it depends on whether you are looking at an entity bean as a distributed object, or you are looking at it as a way to map to your persistence layer. I would prefer to only expose the coarse-grained methods in the remote interface - that way there is no chance of confusing the end user of your component. Never tried this in a real project using CMP so I don't know how well that would work. I did try it using BMP, and I think it has worked well. The current state of using entity beans kind of reminds me of some COBOL programming I did years ago. About 90% of the code seemed to consist of MOVE statements :-)
  22. I see your point and I don't disagree with you. I guess it depends on whether you are looking

    > at an entity bean as a distributed object, or you are looking at it as a way to map to your
    > persistence layer.

    Yes, if you were using an entity bean as a distributed object, what you say makes lots of sense. But these days, that's becoming harder and harder to do. Most of the CMP 2.0 features, for example, are pretty much useless from a distributed-object standpoint. The theory behind an entity bean was that it was a distributed component that needed to pull some long-lived and probably relatively significant state from a data store somewhere in order to perform its work as a component. This is not at all a bunch of primitive fields and relations to other distributed components, which is what CMP 2.0 gives us.

    So, in reality, with the 2.0 spec, we now have two substantively different entity beans -- CMP entity beans, which are morphing into domain model persistence, and BMP entity beans, which are ye olde distributed-component-with-persistent-state thingies. These latter provide useful callbacks for doing the work of loading and storing all that persistent state, which, from a component standpoint, would probably be entire object graphs, documents, etc., and not just a bunch of fields. Which is why object pooling becomes useful -- if a component needs to do a significant amount of work to load its state when activated, then it makes sense to pool that component when its lifecycle comes to an end.

    But I digress. Yes, if you have a proper Booking component that is modeled using an entity bean, then putting the getBookingData() method into the Booking EJB makes good sense. But just bear in mind that your remote interface (i.e., the distributed-component bit) should *not* include methods like getFirstName(), getSocialSecurityNumber(), and other fine-grained persistence-related stuff.

    -Patrick