Blogging Roller

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.