Blogging Roller

Roller is part of homework <a href= "http://spectral.mscs.mu.edu/Ent2002/assignment/04.html">assignment #4 in Enterprise Architecture class at Marquette University. Take a look at the "ass4" links on the <a href= "http://spectral.mscs.mu.edu/Ent2002/ClassList.html">ClassList page to see what the students had to say about Roller and weblogging in general.

We are expecting a half inch or so of wintery mix here in N.C. this evening, so the entire Triangle "metropolitan" area is shutting down, the supermarkets have been completely cleared of milk, eggs, and bread. The web usability experts over at Hesketh.com have put together an entertaining presentation to help relocated northerners in the area understand what is going on.

If you haven't checked the FreeRoller statistics lately, perhaps you should. FreeRoller responded to 702,015 requests for the month of November! I think we should break a million requests per month within a couple of months. [Anthony Eden]

Very cool! The first Roller site (mine) went live on June 8 of this year and now thanks mainly to Anthony there are over 250 Roller-based webloggers out there. If you use FreeRoller, please help Anthony pay for the bandwidth.

There is a very complementary review on Slashdot today of the Manning Press Struts in Action book.

The link below showed up in my referer logs today. I sure would like to read that document, but, alas, it appears to be behind the iPlanet firewall. It looks like somebody is suggesting that Roller or some part of the Roller architecture could be used in the iPlanet portal. Way cool!

<a href= "http://ips.red.iplanet.com/%7Echanezon/ipsarch/suggestions_portal_architecture.html" title="...portal_architecture.html">http://ips.red.iplanet.com/~chanezon/ipsarch/suggestions_portal_architecture.html

You say Tomcat is crap, I say it is not, you say .Net rocks, I say you've got the borg in your belly, and the hits come rolling in (no pun intended).

Castor OIL, the GUI tool for creating Castor JDO mappings from existing database tables, has been brought back to life by Peter Kasson. It was originally written by Lance Lavandowska and donated to the Castor project.[Bruce Synder on the castor-dev mailing list]

As you can see below, Castor OIL takes a different approach than JDOMapper.

• Reads database and creates Castor mapping properties.
• Writes mapping.xml from Castor mapping properties.
• Reads mapping.xml and creates Castor mapping properties.
• Writes java source for each element in mapping.

Using the terms I discussed in my Java persistence frameworks post, Castor OIL supports a bottom-up development approach. The JDOMapper comes close to supporting the top-down approach, but it falls short because it does not generate a database schema (DDL).

I like the XDoclet approach to generating Castor mappings, but this new GUI from Shelly Mujtaba looks pretty cool.

JDOMapper provides a user interface for creating Castor JDO mapping files. The application allows user to import Java classes and map them to an Relational schema . The tool performs series of validations to ensure that classes and fields are correctly mapped. Existing mapping files can also be imported into the tool. [JDOMapper]

Forrester Research has published an interesting summary and analysis of the current state of the app server market.

After working some more with Castor persistence framework, I realized that Castor does not support all four of the development processes I discussed in my persistence framework comparison. Castor only supports "meet in the middle" and I've changed the table to reflect this.

Castor's Source Generator is not really part of Castor JDO, instead it fits in with Castor XML. The Source Generator can take an XML schema document and generate Java classes that represent that schema. This is neat, but it really does not have anything to do with O/R mapping and persistence.

Today, that same five year old found the Wordpad shortcut that I left on the kids computer, right between Sim City and Lego Racers. He started it up and struggled to type in his first attempt at email: a christmas list for his grandmother. He wants the "Spider Man Sky Raider Playset" and the "Masters of the Universe Bashin Beetie." I'm so proud!

My five year old son walked up behind me today as I toiled away on sample code for the chapter that I am working on, he saw the JUnit green bar on the screen, and said "Dad, you did good."

Andy Oliver is on a frightening roll with his <a href= "http://freeroller.net/page/acoliver/20021130">latest rants. Looks like it all started after Andy spent some time playing with Mono, a GPL licensed implementation of Microsoft's C# language and Common Language Runtime. Since then Andy has said that Dot-Net is awesome, Sun doesn't have any balls, and the best way for a Java programmer to help Java is to learn Dot-Net. He has also suggested that Microsoft and Apache hook up because of their joint love of money and BSD. This guy is a dyed-in-the-wool Linux and Java nut. What the hell happened?

Maybe it did not start with Mono. Perhaps something happened at ApacheCon. You know, Comdex was also in town and Microsoft certainly had a presence there. You remember that Andy got very sick with some kind of stomach bug? I think some Rosemary's Baby-like incident occured out there and now Andy is carrying the spawn of Redmond in his belly. He's got the beast in his belly.

Below is the email that I sent to the Hibernate and Castor mailing lists to ask for comments on Ag:

I've written a simple example application that shows how to create a simple web application (a newsfeed aggregator) with a pluggable persistence layer. I used the tried and true DAO pattern to hide the database access mechanism from the rest of the application. I implemented the DAO interface with both Hibernate and Castor.

I did this to learn:

• What are the drawbacks of hiding powerful persistence engine behind a simple DAO interface. What do you loose? Will long transaction support work? What about lazy loading?
• What are the differences between and strenghts/weaknesses of Castor and Hibernate?
• What is the best way to implement DAO with each of the tools?

The code is very simple and (I hope) easy to follow, so if you have a chance please take a look. Look at the HibeAggregatorDAO and CastorAggregatorDAO implementations to see how I used Hiberate and Castor to implement the very same DAO. I'd love to get your opinions on the above topics.

Ag Download: http://sourceforge.net/project/shownotes.php?release_id=125110
Ag Readme: http://sourceforge.net/project/showfiles.php?group_id=47722

I decided that the only way to get a clue about pluggable persistence is to try and implement it, so that is what I did. I wrote a very simple JSP-based RSS aggregator with pluggable persistence via the DAO pattern. I implemented the persistence layer with both Hibernate and Castor and I used the RSS parser from Flock to parse RSS.

In the process I learned a lot about Hibernate and Castor. I am really impressed with Hibernate, but it is too late to go into any details. I do have time to say this: the Hibernate documentation is excellent, especially when you compare it to the incomplete hodge-podge of ad-hoc notes that comes with Castor. I did run into one snag that I have not yet worked around: Hibernate does not support CLOBs!

The aggregator is called, for lack of a better name, Ag. You can <a href= "http://sourceforge.net/project/showfiles.php?group_id=47722">download Ag from SourceForge or just read the <a href= "http://sourceforge.net/project/shownotes.php?release_id=125110">readme.txt.

Ag serves a number of purposes. I'll continue to experiment with Ag as I try to learn more about the advanced features of Hibernate and Castor. At some point, I'll probably merge Ag or some ideas from Ag into Roller. In the shorter term, I hope to use a portion of Ag as the example application for a chapter I'm writing on Data Access for WROX's new <a href= "http://www.wrox.com/books/1861004958.htm">Professional JSP 2.0 book.

I do therefore invite my fellow-citizens in every part of the United States, and also those who are at sea and those who are sojourning in foreign lands, to set apart and observe the last Thursday of November next as a day of thanksgiving and praise to our beneficent Father [<a href= "http://www.christiananswers.net/q-wall/wal-alincoln-tgiving.html">Abe Lincoln's Thanksgiving Proclaimation].

And don't forget to thank Mom too.

They are known as Value Objects, Data Objects, and now Sun calls them Transfer Objects. You only need these if you are doing EJB right? Is there any reason to have your DAO interfaces return Transfer Objects rather than full-fledged "Business Objects" or "Domain Objects" or whatever you call them. I think the answer is NO.

I'm sure this will upset any remaining EJB fans out there: even if you are doing EJB, you can hide the EJB/Transfer object mess behind a set of DAO interfaces.

I've gotten a number of responses on my DAO post. Thanks to all who responded. I think the general consensus is that DAO is a useful pattern, but it can limit your ability to make use of all of the cool features of your persistence framework. I'll try to summarize the responses for you below:

<a href= "http://freeroller.net/page/rickard/20021127">Rickard Oberg says DAO is a useful pattern, but he has not tried to implement it a O/R framework before. Somewhat predicably, he adds that Aspect Oriented Programming (AOP) can play a role in improving DAO implementations.

<a href= "http://roller.anthonyeden.com/page/jcarreira/20021126">Jason Carreirra says that the problem with DAO is that it requires fine grained objects, and that this makes it difficult to "streamline data access with bulk loading and caching."

Matt Raible says DAO works well, but does not like having to modify so many files just to add one field to an object. He'd like to automate the whole process with end-to-end code generation.

Russell Beattie reminds us of his <a href= "http://www.russellbeattie.com/notebook/index.jsp?date=20021012#135748">complexity of J2EE post, but unlike Matt he says that tools and automation are not the answer - we need a better pattern.

All I can say is WOW! and where can I get the source? UPDATE: now that I am fully awake, I should add this: thanks to Mike Cannon Brookes, Atlassian, and whoever else contributed to the java.blogs community aggregator website. What an awesome resource and this is just the start of it!

If you use the DAO pattern, it is possible to completely hide your persistence mechanism from your application.  It is possible, but is it a good idea?  Separation of concerns and modularity are always good things, right? <a href= "http://www.freeroller.net/page/acoliver/20021125#excessive_over_engineering_flexibility_and">Andy Oliver argues that this is not always the case. I think he has a good point. You have to think about what you are trying to achieve. Sometimes separating concerns buys you nothing and just makes your system more complex.

In the case of the DAO pattern, the point is to separate the client portions of an application from the data access mechanisms and to allow the "data access mechanisms to change independently of the code that uses the data." I'm trying to understand the flexibility/complexity trade-offs of DAO. Here are the pros and cons I've assembled thus far:

Benefits of DAO pattern

• The data access mechanism can change independently of the rest of the application.  This makes it possible for you to switch persistence frameworks without upsetting the rest of your application. That sounds great to me because I like to experiment with different persistence framework, but is it generally useful?
• Another benefit is that you get an elegant and modular architecture, but that is pretty subjective. One man's elegant architecture is another man's spagetti-code mud-ball.

Drawbacks of DAO pattern

• Adding an extra layer of interfaces to hide your persistence mechanism adds complexity and could even effect performance.
• Completely hiding your persistence layer behind DAO interfaces may not be practical. For example, you'll want to use Castor's long transaction feature but in order to do so your persistent Java classes will have to implement org.exolab.castor.jdo.TimeStampable. Damn, your persistence engine just poked it's ugly head out from behind the curtain of DAO.
• Different persistence frameworks may have totally different development paradigms and forcing them into the DAO pattern may force you to make sacrifices.  You will end up supporting leveraging only the least common denominator features of your persistence framework.

Personally, I like the DAO pattern and I like the idea that DAO can help you achieve a pluggable persistence layer. I like the idea that you can switch from EJB to Castor, and then from Castor to Hibernate if you wish to do so.

What do you think? Is the DAO pattern a good thing? Is pluggable persistence a desirable design goal?