Blogging Roller

Andy Oliver is on a frightening roll with his 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 download Ag from SourceForge or just read the 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 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 [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:

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.

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 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? 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?

I'm not going to be able to make it to the RTP WebShere Users Group meeting tomorrow (Tuesday Nov. 26), but it sounds like an interesting meeting, especially the Struts Builder bit.

WSAD is the successor to IBM's VisualAge for Java. It was first released at the version 4 level about a year ago, and now, with version 5, it moves to an Eclipse 2.0 base, and adds full J2EE 1.3 support, as well as numerous enhancements. Roger's talk will introduce WSAD 5.0, with an emphasis on the Web Development side. He will also demonstrate some of the new items, including Struts Builder and Cheat Sheets.[From the RTP-WUG meeting annoucement]

I'm working at home this week on various geekly projects and I'm spending lots of time with Leo. He was already a happy little guy, but now that he can sit up he is overjoyed. You can see he is so proud of himself. I think that this time, from about 4 months to a 9 months old, is the sweetest time in baby development. Babies at this age can't move around and get into trouble. They can smile, laugh, coo, goo, and babble in a pleasant way, but they can't talk back at you. They never say "Dad, you are so lame" even when they should.

Jeff Duska is forgetting a couple of things that many Servlet/JSP developers (myself included) often forget. He is forgetting the distributed nature of Servlet apps and he is forgetting the WAR.

Someday, when your app becomes incredibly popular, you might find that you need to distribute the load across multiple worker processes on multiple computers. All the major app servers support this, does your app? In a distributed configuration, if your app writes a file to the file-system on one computer, you won't be able to get to that file on another computer. If you want all instances of your app to share a file, then this is a problem. If you are just writing a simple little temporary file, which sounds like Jeff's case, then this is generally not a problem.

Even if you are only writing a temporary file, you still don't want to write it inside your Servlet context. When your app is packaged in a WAR file, may not be able to open files inside the Servlet context. If you are just writing a temporary file, it might be better to use one of the static java.io.File.createTempFile() methods to get a file.

Anthony applied the Roller 0.9.6.4 build to FreeRoller today. The RSS fix seems to have worked and I am no longer seeing old FreeRoller posts pop up in Aggie. It is nice to see Aggie report the "Channel has not changed since last read" message.

I fixed those two RSS feed bugs that I mentioned on Thursday. This site should be behaving perfectly with RSS aggregators that try to track which articles are new, so please let me know if you see any misbehavior.

No, it's not just you Darren.  I use Aggie and I have noticed that posts from Roller-based blogs often show up as new when they are in fact old.  Others have reported similar problems with FeedReader and now you are seeing this problem with Radio's aggregator.  I'm hoping that by fixing the following two bugs will resolve this problem:

I knew that Alan Williamson, Editor-and-Chief of Java Developer's Journal, was the CTO of N-ary Consultancy.  I did not know that N-ary has it's own blogging software and that this software runs the Blog-city site.  The blogging software appears to be Cold Fusion based, but it may be a fusion of CFML and JSP.  Blog-City is powered by Blue Dragon, N-ary's own proprietary app server that has the "unique ability to combine JSP and CFML and to share resources between those pages."  Wait, isn't that what Cold Fusion MX for J2EE does?

Disclaimer: The title Dragon Tales is not meant to imply that anybody is telling a lie. My kids like the PBS show Dragon Tales and Ord is the first thing that pops into my mind when I hear "blue dragon."

Dominic DaSilva and Mike Cannon Brookes both read my recent Roller persistence proposal as a proposal to escape from the Castor persistence framework.  That is really not really the case.  I want to make it easier for Roller to make full use of Castor and at the same time I want to separate the Roller business logic from from the Castor-based persistence logic.  I don't like the fact that the Roller business tier is littered with calls to Castor and I want to separate concerns.

Why can't Roller make full use of Castor now?  The answer is in the history.  Roller is constrained by it's own EJB legacy.  When I originally wrote Roller back in the Spring of 2001, I implemented the Roller manager objects as EJB Session Beans and the domain objects as EJB Entity Beans.  I quickly learned that EJB Entity Beans are way too heavy.  I started to take advantage of XDoclet's ability to generate light-weight Value Objects.  Eventually, I came up with an architecture where the presentation tier knew nothing about EJB.  The presentation tier only knows about the business tier interfaces and the Value Objects that those interfaces returned or accepted as arguments.  Once I got to that point, I was able to completely swap out EJB and switch over to Castor.

So, Roller uses Castor for all persistence now, but it still uses the EJB Value Objects generated by XDoclet.  To add a new persistent object to Roller, you create an abstract class that extends javax.ejb.EntityBean and you mark that class up with XDoclet @ejb, @castor, and @struts tags.  This new class will not actually be used by Roller at runtime.  It is used at build time as the basis  for XDoclet code generation that generates Roller's Value Objects, Castor mapping file, and Struts form beans.

As I state in the proposal, I'd like to stop using the Value Objects for persistence.  They are just dumb data buckets and we need them to be real business objects.  That said, I hate the idea of hand-maintaining code that was once generated.  I'm conflicted.

Now, on to the other issue: separating the Roller business logic from from the Castor-based persistence logic and possibly attaining persistence layer pluggability.  I feel less strongly about this because 1) if Roller moves from Value Objects to full fledged business objects then much of the business logic can reside in those objects and 2) Castor works pretty well and at this point no other persistence framework offers a compelling reason to switch.

Like Dominic, I'm on a "quest for a good Java/XML O/R mapping framework."  None of the competing persistence frameworks offer me a really compelling reason to do the work required to switch, so I hope to learn to use Castor better and and at the same time try to design away some of that work.  

One other thing.  I tried to get some design assistance from the Castor and XDoclet folks in the past, but I came up short.  If you are an XDoclet/Castor expert, please speak up and help us make Roller a best practices example of XDoclet/Castor usage.  Read the Roller article, read the proposal, get on your high horse, stand on your soap box, or climb the stairs into your ivory tower, and tell us what we are doing wrong and how we can do better.

Triangle-based Webperformance, Inc. has published a Servlet Container Performance Report that compares Tomcat, Orion, Jetty, Resin, SunOne, and Websphere. The testing methodology and the results are interesting and really show off the Webperformance product. The conclusion is that there is no clear winner in the Servlet-only performance race. UPDATE: Webperformance left Weblogic out of the review, but Kasia did not.

Cedric Beust reports on what he calls the SunOne/.Net Smackdown that took place yesterday out in Silicon Valley. As you may know, planning is underway for a similar shootout here in the Triangle.

The goal of this [BasicPortal] project is to leverage a combination of several of the Apache Foundation's Jakarta projects into a simple vertical sample application that contains the functionality common to 80% of web projects -- we let developers customize the last 20%.

On the Struts mailing list, somebody asked for Struts-based CMS and Basic Portal was the answer. BasicPortal aims to be a best practices sample app, so I'm going to take a close look at the persistence layer.

Dominic has put demos of Java-based webloggers CocoBlog, PersonalBlog, and Roller online for your evaluation. Very nice. Thanks Dominic!