Discussions

News: Chapters on Entity Bean Alternatives and Messaging Posted

  1. Bitter EJB review chapters, 'Bitter Alternatives' and 'Bitter Messages' are now available for review. 'Bitter Alternatives' discusses some fundamental problems with entity beans, and examines alternate solutions that can address these problems. 'Bitter Messages' reviews the recent integration of JMS with the J2EE platform in the form of message-driven EJBs.

    Download and Review Bitter EJB Chapters 9 and 10

    Threaded Messages (16)

  2. I agree with most of the points in the entity bean alternatives chapter. However, you don't have to wait until the Bitter EJB book comes out to read a critical appraisal of entity beans along with a discussion of the alternatives.

    My recently published book, Expert One-on-One J2EE Design and Development devotes a chapter to the problems with entity beans. It also has, IMHO, a deeper chapter on alternative persistence approaches, with detailed coverage of JDBC, including discussion of error handling strategies and a downloadable abstraction layer that makes JDBC much easier to use and easier to integrate with the DAO pattern.

    There's a brief discussion of how entity beans and persistence fit into an overall architectural model in the sample chapter on the Wrox site.

    Rod
  3. Rod:

    Congrats on an excellent, very practical book! It must have been a huge undertaking but you made it happen.

    Now let me ask one question on entity beans vs. JDO: if I use CMP 2.0 entity beans (via local interfaces, session facades and DTO's) strictly for ReadOnly purposes (obviously a vendor extension to the EJB spec but I work for a company who standardizes on WebLogic), do you see JDO being a better alternative still? I prefer EJB because there is a lot of industry traction on it, whereas JDO has yet to gain full support by the Java heavyweights or Apache. I am worried about the current niche JDO players for their uncertain long-term viability. Also, do you see proprietary O/R mapping tool vendors (TopLink and CocoBase) moving to the JDO standards in order to grow or even survive?
  4. EJB are definitely more strategic. That's actually the biggest primary advantage. It's not an iron-clad protection of your investment, though. Keep in mind that EJB went through tremendous changes between 1.0 and 2.0. You'd be practically looking at a rewrite if you'd standardized on EJB 1.x anyway.

    In truth, you've got to balance. We used JDO as a reasonable example of an persistence framework. The truth is that you could not have made a perfect decision in the last 10 years. If you bought the early hype and market momentum and went with EJB 1.0 CMP or BMP, you'd be rewriting for 2.0 or you'd be saddled with a performance pig. If you'd bought the industry's leading OR mapper and the industry's leading app server, you'd be sitting now on an uncomfortable combination of an Oracle mapper and a BEA application server. So your point about things being very early for JDO is a valid one.

    We'll try to make that point more strongly.
  5. <eric>
    If I use CMP 2.0 entity beans (via local interfaces, session facades and DTO's) strictly for ReadOnly purposes...do you see JDO being a better alternative still? I prefer EJB because there is a lot of industry traction on it, whereas JDO has yet to gain full support by the Java heavyweights or Apache. ...Do you see proprietary O/R mapping tool vendors (TopLink and CocoBase) moving to the JDO standards in order to grow or even survive?
    </eric>

    There are a couple of issues here. Read-only entity beans are supported by several vendors, and they can perform well, so long as EJB and calling objects are collocated. Otherwise the EJB cache is too far away from the components (such as web tier components) that need the cached data. However, JDO also has good caching support.

    As for industry buy-in, TopLink is supporting JDO. CocoBase hate JDO, but seem to be an exception. Numerous other vendors seem to be coming towards JDO. I think that the vendors who do support JDO, such as Solarmetric (Kodo) seem to understand relational databases better than most EJB container vendors. Yes, EJB 2.0 has more industry support at the moment--I think it's the old issue of whether the inferior alternative that hits the market first will prevail. My own feeling is that EJB 2.0 CMP is just _too_ inferior, and that people will need to look for better solutions. For example, Bitter EJB talks about CMP's complete failure to support inheritance...

    Rod
  6. I have not touched JDO and probably will not do so until Apache's ObjectBridge fully supports JDO. Why do you think the major app server and O/R mapper vendors are slow in endorsing JDO, if it is such a superior alternative to CMP entity beans? Because they have invested so much money in CMP containers and they want to squeeze extra mileage out of that?

    Also, it sounds like Oracle is in a unique position when TopLink is fully JDO compliant now they have got an app server comparable to WebLogic. In the meantime BEA is taking the MSFT approach, i.e., provide drag-and-drop tools (WorkShop) with the hope to make J2EE development easier. So maybe the market share will shift in ORCL's favor when that happens?
  7. Congrats on an outstanding book. I can only hope that we can achieve the same level of quality or success. Keep in mind that we're trying to raise a flag and describe the common mistakes that EJB developers are likely to make. I think that knee-jerk selection of CMP over JDBC or OO persistence frameworks or mappers is common enough that we wanted to devote parts of three chapters to it.

    I think that readers will like the quality of writing and wisdom in this book. Let us know how we succeeded.
  8. Bruce, I think we're pretty much in agreement, and it's great to see another book putting this case. Btw, I thought the entity bean alternatives chapter was very good. I like the writing style--it's very approachable.

    Rod
  9. The "Bitter Alternatives" is a good introduction to entity bean limitations but it lacks depth and substance. If JDO is presented as an alternative to entity beans, we want to see performance comparisons, not just code snippets showing JDO is easier to code. To me CMP 2.0 entity beans is easier to code because I use XDoclet.
  10. Thanks for the outstanding points. Rudimentary measurements would be a good idea, but it's a bit of a pandora's box. Do you measure with or without a caching extension? Clustered or standalone? Database size? Model complexity? Read/write ratio? We decided against doing something too simple, and use logical arguments instead. Someone is going to be unhappy with the results. A more exhaustive benchmark is way out of the scope of this project.

    Instead, we'll make the case in chapter 7 that if you use CMP, then you've got to worry about considerable overhead with the container that provides services that are duplicated in the session facade. We also make the case that you do duplicate a whole lot of effort.

    Finally, thanks for the point about depth. It's a good one. I think you'll find a whole lot of books that take the opposite approach to ours, and write very narrow books (we couldn't justify the time investment) or phone books. We could have written a phone book. I hate writing and reading those, and it's tough to supply that kind of volume and maintain good quality. Instead, we present a series of what we think are the most common and important EJB mistakes, and cover them in sufficient depth to make our case. We used respected consultants like Mike Clark (author of JUnitPerf) and Patrick Linskey (I recruited him for his knowledge on persistence alternatives.) We want the book to be accessable to intermediate EJB developers, but we also want to give good advice. Let us know how we did on that score.

    Re. XDoclets, it's a tremendous technology that can shield you from some of the EJB complexity. It can't help you map inheritance onto a relational database, or handle the full richness of an object oriented model. EJB CMP, even with XDoclets, is far from a silver bullet, in my mind.
  11. Bruce:

    Thank you for responding to my criticism with such a positive attitude. So far I have read 3 out of 4 chapters posted on TSS and I must say they are quite insightful, informative, and are written in such a clear style that people who are relatively new to EJB should understand the material without much difficulty. I think so far you have been successful in relating your message to the "middle tier" of J2EE developers, who should benefit the most from the current book, as with your popular Bitter Java book.

    I am a bit picky here maybe because I have learned a few lessons the hard way, and wanting to get the most in-depth opinions of J2EE experts about EJB's, particularly on CMP 2.0 beans. Another reason is perhaps because I just finished the first reading of Rod's book (started 2nd reading of key chapters). :-) I think Rod has successfully targeted his book at the more senior J2EE developer community, while your book appears to be reaching out to the great masse.

    Best wishes to you and looking forward to seeing the book on the bookshelves soon.
  12. With respect to the "Bitter Messages" chapter, one concern that I've got is that the suggested solution 10.10.2 (to slow-running MDBs) suggests handing on the message to an internal queue serviced by worker threads.

    Unless I'm missing something, you have to create your own worker threads, which is surely 'illegal' for code running within a J2EE server. The only alternative I can see would be to re-queue the messages to other MDBs, and even then surely simply leaving the container to use it's threads to service other messages from the original MDB queue would be better.

    Gwyn
  13. Exactly. Not only are custom processing queues not spec-compliant but they work around the container's
    resource management.

    But they are even dangerous: the solution presented in the book forgets to mention acknowledgement. If I post the message to a threadpool and return afterwards, the message is acknowledged. If the container crashes in that moment - the message is gone. To be safe, the MDB would need to wait for completion. This only pays off if there is inherent parallelism in the message. In the given context, it seems as valueable to spend my CPUs on several messages at once.

    A question to the community: I have deliberately chosen JMS as a persistence mechanism. An application that would previously have a simple thread-pool to handle jobs (that trigger new jobs, ...) needs to survive crashes. So I introduced a JMS queue as the job queue and send messages to myself. In combination with CLIENT_ACKNOWLEDGE this seems to work very well and reasonably fast. With SwiftMQ IntraVM connections even the network overhead can be elided. Anyone else on that road ?

    Last question: anyone who uses filesystem-based JMS providers. How do you handle backup issues (consistent with your database) ?

    Matthias
  14. Bitter Messages[ Go to top ]

    <gwyn>
    With respect to the "Bitter Messages" chapter, one concern that I've got is that the suggested solution 10.10.2 (to slow-running MDBs) suggests handing on the message to an internal queue serviced by worker threads.

    Unless I'm missing something, you have to create your own worker threads, which is surely 'illegal' for code running within a J2EE server.
    </gwyn>

    <matthias>
    Exactly. Not only are custom processing queues not spec-compliant but they work around the container's
    resource management.

    But they are even dangerous: the solution presented in the book forgets to mention acknowledgement. If I post the message to a threadpool and return afterwards, the message is acknowledged. If the container crashes in that moment - the message is gone. To be safe, the MDB would need to wait for completion. This only pays off if there is inherent parallelism in the message. In the given context, it seems as valueable to spend my CPUs on several messages at once.
    </matthias>

    Excellent points, Gwyn and Matthias! My apologies for the delayed response. I debated long and hard before including this supplementary solution to slow MDB instances. I finally decided to err on the side of offering up this solution, though noting that it involved digging deep into the bag.

    As you accurately point out, MDB instances shouldn't attempt to manage threads. My thinking was that a separate consumer component would be responsible for managing those worker threads, if in fact the handling of a message had potential parallelism that warranted such complexity. Nevertheless, it may certainly raise more issues than it solves. As such, I think the section is more trouble than it's worth. I'm planning to remove it from the book.

    Thanks for taking the time to keep me on the rails!

    Mike
  15. Chapter 8 misses an important benefit of the Entity Beans.

    You write off the transactional capabilities of the Entity Bean container because they can be delegated to the Session Facade. This absolutely makes sense when considering the transactional capabilities of the back-end datastore. But the session facade can not handle the transactional semantics of the fine-grained object cache provided by an entity bean container.

    Consider entity beans deployed with commit-option A. After manipulating individual object instances in a complex transaction, a rollback can restore instances to their original state without requiring a resync with the database. This is beyond the capabilities a session facade over JDO.

    Be sure to check out Marc Fluery's 'Blue' whitepaper. He primarily praises the use of entity beans for the transactional caching capabilities.
  16. Great. But what a suprised to see .doc still used as a standard format. It is always a pain to read this kind of document when you do not have MsOffice.


    Hey there are people out there who do you not want to spend money on buying an expensive office suite. It would be nice to take them into consideration by using a more standard format.

    Thanks,
  17. The .doc format is provided to support the authors more than anything else. With a community like TSS, and the popularity of the Bitter Java book, the feedback quantity can easily grow beyond our ability to respond. Change tracking in Word makes it a viable alternative...we can selectively scan and integrate changes rapidly.

    Thanks for your patience. Having a word processing document makes it easier for the authors, sometimes at the expense of the reviewing community.