Forum OpenACS Q&A: Response to A Technical Paper on Java

Posted by C. R. Oldham on


Thank you for the paper. It is an interesting coincidence--last week I began looking at Tomcat, Turbine, Cocoon, Xalan, and the other Java based options for building web applications. I've already arrived at some conclusions, but first let me do a little critical analysis of your paper.

I agree completely with what others have posted regarding comparison of apples and oranges. I think what you might need is a comparison of OpenACS with the various servlet toolkits already out there. For example, compare AOLserver+OpenACS with Tomcat+Turbine+Velocity (see, or Enhydra+Barracuda (

I especially appreciate your observation that layering data abstractions on top of the relational model breaks SQL semantics. That was my first question when I looked at Turbine--how do I get at the data in the RDBMS? Turbine provides the Peer object (to be fair, you don't have to use them) that does the O/R mapping but Peers are really simple and make doing joins hard.

Some things you haven't covered that might be useful:

  1. Debugging AOLserver+OpenACS can be very difficult, especially when the TCL code is complicated. My shop has wasted hours on debugging when a good, visual debugger that could let us step through the code and see where we were screwing up would have reduced that trial to just a couple of minutes. There are already excellent tools for debugging of java servlets. Is there anything out there for TCL that works with ACS/OpenACS/AOLserver?
  2. You don't spend any time discussing one of the main reasons people go to servlets--the model-view-controller paradigm. So much of the flow control in OpenACS is page-based, and complicated applications can get out of hand quickly. The MVC paradigm (theoretically) can help you overcome that.
  3. Which brings me to my next point--there are lots of tools out there for doing CASE and they are heavily weighted towards Java nowadays. You could argue that an AOLserver+OpenACS shop could use those tools anyway, and we just have to do some translation somewhere, but tool support in general seems to be to be a big issue.
  4. And in the same vein as tool support, there is library support. There seems to be a plethora of library support out there for java, but precious little for Tcl embedded in AOLserver.
  5. Others will say that for large applications, the world is moving away from "business rules in the database" to "business rules in the middleware (servlets)". It seems to me that if I can't represent my rules in the database, and some of mine won't work there for sure, I'd much rather have them in Java than TCL.
  6. Just a few observations, some probably outside the scope of your paper.