Friday, October 06, 2006

The mile high stack

Since getting back into doing some Java/J2EE web development, I'm constantly struck by the sheer number of mega-frameworks that I feel I probably should know. It's overwhelming, it gives me a nervous twitch, like I could be investing lots of time in some framework that turns out to be inferior because I have no way of comprehending what else is out there.

How do Java web app developers ever get anything done?

Here's a list of frameworks and APIs that I've come across in my current project, all of which could have some relevance to my project:

Java Servlet API

JSP syntax

JSTL

JSF

MyFaces/Tomahawk JSF components

Oracle ADF JSF components

Java Facelets

Hibernate

iBATIS

EJB 2

EJB 3

JBoss SEAM

Spring

Struts

WebWork

SiteMesh

Tapestry

AppFuse

Log4J

JUnit

JMock

JDBC

DBUnit

Cactus

Maven

Cargo

Ant

Tomcat

JBoss

Eclipse

MyEclipse

Oh ... and I need to determine which ones of these can work together, and which of my tools will tolerate which technologies. Aaaaah!

To be clear, my application is basically just forms that drive SQL queries. I don't even care so much about security. However, a goal was to try and use best-practice patterns and technologies, to ensure the application could scale up in the future.

Now, I'm pretty good developer, I know Java (the language) well and I learn quickly. But several of the pieces above would take me a week or more (each) to learn properly. Obviously some are easier than others, and many are directly competing. But how do I know what to choose? How do I know where to invest my time?

I looked for books, but it seems that many of them are out of date by the time they hit the printers. In the blogsphere, there are people who seem to be able to pick and choose between all of these. Power to them, but there is not a great consensus on what is best this week.

If there is some canonical book that covers an end-to-end process with best practices - please, I'd like to know. :)

But I started thinking about how this works in the Plone community. Im sure new users feel a bit overwhelemed, and that we could do things to make it easier for them. However, based on own experiences from when I first played with Plone, it wasn't nearly so bad:

Plone is there, you can touch it and feel it and play with things to see how they break.

Python is terse and readable.

Although Java kicks our ass on API docs, it's easier to follow the actual code since the .py files are all there and legible.

I learn best by example. Like most people, I started with a few copies of some page templates and later some Archetypes classes. That meant I could get results very quickly.

Of course, I'm comparing apples to oranges here. Plone is a CMS and a platform for CMS-like systems. J2EE is much wider in scope. However, my application is not so unique - I need forms, page flow logic and database queries. Maybe one day some CRUD logic, and a few pages of text.

Obviously, this is all in the terriotory of that infamous Better Web App video, and the cliche exodus of Java coders to Ruby-on-Rails. Fair enough, but I'd like to think that it's not impossible to be productive and feel in control of a Java-based solution. This is often a question of skills (people learn Java in school), of prior investment (people have been trained in Java already), of back-end systems (that already run in Java), and of trust (for business-critical components that may feasibly need a web front-end). I refuse to believe that just because Java is strongly typed and compiled, this can't be done right. So most likely I just haven't discovered that framework yet.

However, there is another argument - Java is great for the middle tier, but less productive for the front end. Perhaps we should put more time into finding a bearable way of defining service layers that would let you build your user management and GUI in Plone or Django or Rails and let actual business processes take place in Java beans or EJBs. At least I think that separation would make a lot of decision makers more comfortable - Hibernate, EJB, Oracle (or Postgres) on the back-end, sexy GUI app on the front end that is infinitely more dispsable and lower risk, and is more likely to be what users want if it is written in a framework that encourages agile and rapid development. It may even help to ensure that the middle/back-end business objects are completely decoupled from the GUI and facilitate SOA.

22 comments:

"However, there is another argument - Java is great for the middle tier, but less productive for the front end."

It might also be that a software stack or framework that is right for the middle tier is not right for the front end. So even if you are writing both in Java, they should be fully seperated with framework designs driven by their different goals.

If they are written in different languages, then you are sure to have different frameworks. But maybe it's the framework separation and not the language separation that is really the important part.

Thanks for the pointer. I guess the point is, your platform of choice is JBoss SEAM, including its toolset. The further you stray from that "known good" configuration, the harder, I imagine, it will be to make the pieces fit together.

It is not all too dissimilar to our use of MyEclipse, which worked great until we needed JSF which it didn't support at that time. Ironically, SEAM looks quite good (but new, and thus more risky and less documented), though I'm feeling a bit ambivalent about JSF these days - some things that should be quite easy are just incredibly hard, and there is way too much magic going on behind the scenes. I imagine the tools and framework components all make assumptions about the view technology I'm using.

Indeed there are lots of different frameworks available especially for the presentation stack. However they all do MVC in more or less the same way, so they are not so different after all.

As far as using the JBoss product line is concerned, I suppose that you can compare the situation with all the Linux programs available: there are just too many of them to make a choice, at some point one needs a distribution.

The RedHat JBoss line of products is vertical from the application server to the portal, to the IDE. So I guess that this is a choice that makes sense.

Seriously, I feel your pain. We have had to wrestle with the java framework jigsaw puzzle for a while now too, since that is all that Central IT supports, and we are closely tracking Sakai , and may one day want some of our tools to converge with their universe.

Absurdly, for one of our larger applications we actually protyped the thing in Plone so we could sic the UI team on the project sooner (much of the work was front end). We ended up going with spring-hibernate-velocity - To me, JSF smells as bad as EJBs, and was horribly at odds w/ the way the rest of the web (especially this newfangled 2.0 thing) works. Its statefulness was really hampering our ability to interact with it ways that the rest of the web is currently expecting.

Well, there is a thing called, henh.. ".NET".Seriously I feel your pain everyday. There are just too many J2EE stuff out there. We would be far better off if there is just one central JavaSoft to control everything in Java. Well, that is called monoploy. Freedom has a cost.

"It may even help to ensure that the middle/back-end business objects are completely decoupled from the GUI and facilitate SOA."

And what you mention, of course, is the holy grail - the complete decoupling.

We perl folks have lots of web application frameworks too - Jifty, Catalyst, Maypole, CGI::App ... The list goes on, and I know that I could have spent lots of time working on figuring out how to use them. At work, we have a legacy mod_perl application framework which is so vast that decoupling our libraries to fit into another framework would be a waste of time.

My suggestion would be to build your libraries to be framework and presentation agnostic (Not that I've been able to accomplish this in its entirety ... hey, i can dream, eh?) Make your libraries pass all tests from the command line. Then, you can be free to try these frameworks without too much of an investment. You are especially in good fortune that your application does not need to do anything unique. Because of this, you may be able to bootstrap two or three that catch your eye at first glance, and choose from those.

Where is your application most likely to grow? Presentation? Reporting? Does any one framework cater to the most likely area of growth?

Oh - and if JSP is anything like PHP, I'd avoid it like the plague unless you have a templating system ready to go! :)

Please take some time to fill out a survey for a school project of mine, I need to have atleast 50 results by wednesday! Please tell your friends and family i'd greatly appreciate it if you could help me out! Thanks!

I have read your blog carefully and like it a lot! We have the same opnion! Could you check my blog at: www.muslimfriends.com/i/free to check my blog title: helenwang`s blog"? May be we can talk further and be friends.