vsbabu.org

Fake J2EE is not that bad!

A J2EE Application

Recently, I was (un)fortunate enough to witness a web application that was already deployed and in use for over an year. At the time of installation, the main marketing points appeared to be:

1. To modify the layout and design, programming knowledge is not necessary. The vendor had developed a proven templating scheme that plays well with existing HTML editors.
2. It doesn’t lock you to a particular operating system since it is written in Java.
3. Since it employs J2EE, it scales, rocks and keep your job safe (I sensed the last one, but it was not explicitly spelled out.)
4. It runs on any servlet container.

Quick inspection of the code revealed it was a straight-forward JSP application (or MVC type 1, if you will). A controller servlet handled all incoming requests. The controller checks if the user is logged in and maintains session information. Rest of the pages are vanilla JSP+HTML forms that display data from about 4 RDBMS tables. It is a purely relational application that happen to get a Java front end.

Apart from the single servlet, there is nothing J2EE'ish about this application. The principles and the code used looks straight like ASP or PHP code. The templating was simple variable substitution mechanism --take a web page, search and replace ##XYZ## with the value of variable XYZ and send it to the browser.

Is it really all that great?

There were several missing pieces:

1. No make/Ant/Maven build file. A DOS batch file does the building and packaging.
2. Absolutely no unit testing code.
3. Several external Jars. I couldn’t find any reason for about 40% of them.

The customer’s design needs included changes to the stylesheet and logo. The application is used by about 30 users and there is no scalability issues. I suspect it won’t scale when about 300 people hit the current server, mainly because of multiple trips to database and page parsing for each request.

J2EE purists can immediately see that this is not the proper way of doing things in the J2EE world. No MVC2, no EJBs, no OOP! The code base is about 10000 lines. It took about 3 man months to develop and deliver. Not impressive by any means.

Is it worth it?

However, in my humble opinion, the vendor wins:

1. His product satisfies all he promised.
2. He sold it and made money!
3. The customer had nobody with enough foresight to ask about how easy it is to change the design of forms and record display --the templating system can’t handle logic.
4. The developers had a J2EE project with about 10000 lines of code to add to their resume.

He has followed the XP principle of YAGNI to the heart

Customer is apparently quite happy too. It met their needs. It met their budget and schedule. Additionally, their manager can now join the rarified ranks of people who employ J2EE applications --remember the old quote about nobody getting fired for choosing IBM?

How about purity?

I am sure an experienced J2EE developer, armed with his/her favourite IDE can deliver a professional product with appropriate build system and unit testing code with half the lines of code. Rest might be absorbed by proper choice of existing frameworks like Struts, that you don’t need to maintain. On the same token, I estimated about 3 man days of work and 300 lines of code to provide same functionality and a lot more --XML-RPC services, templates you can edit using WYSIWYG tools, database independence etc.-- using Zope.

What is the silver bullet?

Or, I could use Struts --to keep clients sold on SUVs and J2EE. Don’t get me wrong, I like Struts. I like JSP. I like PHP. However, none of these can be easily edited in an existing WYSIWYG tool like DreamWeaver or FrontPage or Mozilla Composer; in an as confident inspiring manner as editing plain HTML.

The templating specification closest to the silver bullet of separating logic and presentation, in my experience is Zope Page Templates Designers can actually use the tools they are familiar with, to produce nice designs. After programmers add their logic, designers can still use a WYSIWYG editor to change the design without the fear of messing with the logic. Apart from ZPT --and the one from the example above, which is obviously very limited--, all other templating specifications I’ve seen are for programmers, by programmers.

Personally, I think programming and creative design require entirely different skillsets. I suspect most programmers would be shocked if a graphic artist told them how their code should look like. I think, programmers need to respect creative artists, by not asking them to expand their skills. Quirks of HTML and CSS and browser compatibility are good enough to annoy most creative people. As programmers, should we add more things to add to their burden? For example, shouldn’t it be waste of their time and energy to worry about what <bean:message key="page.title"/> means?

About acquiring knowledge that are not theoretically needed in one’s profession, Sherlock Holmes was known to be “egotistically proud of the vast fields of his ignorance,” including matters of “literature, philosophy, and astronomy.” He was equally proud of the vast fields of his knowledge about the matters that mattered to his profession.

If everybody is happy, what is the problem?

N-tier architecture, ultra scalability, portability are all valid reasons for decision making. Are over-engineering and heavy marketing too? I don’t think so. These aren’t reasons good enough to be unrealistic. If you are a project manager who has to factor in the development, support and code maintenance costs, it would be wise to properly analyze a heavy-weight architecture. Customers may have some patience during initial development. Such patience will not be there when they’ve change requests post-installation. As the architecture complexity grows, the response time to change requests usually grows as well.

Actually, for the above example, there is no problem! Yes, it is not a purist’s solution. Nevertheless, 99% of the change requests are simple ones that can be solved within an hour by people with purely HTML knowledge.

I suspect this solution was developed like how it was, mainly because the developers were learning to program Java servlets and JSPs. Had it been developed by a J2EE guru, I’m truly concerned if the system would've ended up requiring a programmer to make changes. Very often, we tend to develop software that are programmatically sound; but are hard for non-IT folks to customize. As usual, there is an automotive equivalent that we can use as an analogy

“For the users, by the designers, of the programmers”.

Update: May be Java Zope Page Templates is the answer?

1. Good points all, but I have to say, anytime someone points out that Zope comes with everything and the kitchen sink, I have to wonder why nobody ever mentions its complexity or speed issues. OK, sometimes they do, but not with equal emphasis let's say.

   Admittedly I know very little about it, but it's way more baffling to get up to speed than a servlet/JSP setup, and is *sluggish*. Not always slow, but rarely has that "snap" that most apps do. And Plone, while nice in an out-o-the-box kind of way, IS slow. Painfully so. I suppose enough caching of static pages or objects, and funky caching or whatever can help a bit, but they should tell that to all those running painfully slow Plone sites.

   In short I'd love to (learn more and) be able to always use Zope, but until it's made clearer and zippier (or clearer how to make it zippier), it's not the be-all end-all many seem to imply...

   Posted by: TG on November 4, 2003 11:21 AM

2. I'm not saying Zope comes with everything - for example checkin/checkout version control is quite difficult (then again, which Java App Server lets you put objects in CVS)?

   You could just ignore Zope Component Developer's guide and create your code like Servlet/JSP using PythonScripts/PageTemplates, ;-) It is almost the same way - if you think of Zope HTTP publisher as the "controller". You automatically get a really good object database system too (though no one will prevent you from using a SQL queries).

   I've seen respectable performance from Zope using systems with lot of RAM.
   

   Posted by: Babu on November 4, 2003 07:57 PM

3. Ah, I didn't really mean *you* said it comes with everything, though many people do. Poor wording on my part, my apologies.

   That said though, I really would like to use all(lots,some) of the functionality it provides - it's just quite opaque to newcomers. Hopefully 3 will be better in this regard.

   Quxiote and Webware are two examples of "un-Zopes", Quixote using more Zope ideas than Webware (more MVC-ish). The flipside though, is you have almost no collection of prewritten components like with Zope. So we need a nice middle ground!

   And of course some sites manage to get Zope running quick enough, but it seems non-trivial. I guess that many dynamic lookups and traversing has to be paid for...

   Posted by: TG on November 4, 2003 11:58 PM

4. please give the j2ee projects

   Posted by: arun on June 12, 2004 12:13 PM