RAD development and domain modeling

Java web programming suffered bad development performances in the last years, mainly related to the complexity of the presentation layer. As a coordinator for J2EE learning classes, I found often embarrassing to define a competence stack for the web programmers which included Java, J2EE concepts such as Servlets and JSPs, a bit of XML and HTML (and HTTP of course) some JavaScript and a MVC (so some Design Pattern concepts got in as well) framework, normally Struts. Given that in another language, such as Delphi or Visual Basic, programming for the presentation layer is made ultra-simple, this pile of necessary knowledge really looked scary.

Moving from Struts to JSF

Although the JSF approach is far from being perfect, it’s just a great leap forward compared to the old mainstream Struts:

- at the architectural level, JSF removed the need for a layer, making it possible for the presentation layer to manage model objects instead of dealing with extra-flat ActionForm classes. In many cases, inability to handle data which was not a String led to an extra layer of DTOs to simply handle transportation and type translation between the web layer and the business layer (pretty boring stuff indeed)

- in the IDE, designing a web user interface has become simpler and more productive since JSF support is built-in and not only an a not-so-well-designed-plugin. Many components are designed on top of basic layers (Servlets and JSPs), so you normally shouldn’t bother about them.

Data Aware components

JSF toolkits offer also the possibility to use data-aware components in a web oriented paradigm. This way you can expose a RowSet directly on the web page and rely on the data-aware component for synchronizing page data with the underlying database. It’s definitely not OOP but it might come in handy in many cases.

The main message is probably intended for the average orphan Delphi programmer: “your paradigm works in java as well, and on the web too!”.

Everybody happy?

So, looks like the Java web developer is now given two tools when constructing a simple web application. Anyway my feeling is that data-aware components are just a bad idea for a developer with a J2EE background.

1) data-aware component are popular in not-so-OOP languages (ok, languages jave OO capabilities, but I’ve never seen a VB programmer define a domain model), in such a scenario your application is just a collection of CRUDs (create-read-update-delete) and this is not exactly a great idea.

2) You have to define a place to put your business logic anyway, and since JSF allows you to use POJOs …why not use the POJOs? If you prefer to put all of your domain logic in the presentation layer you’re free to do it, but I have to warn… you’re probably going to hurt yourself.

3) Data-aware components fits well in closed client-server architectures. Here the architecture is not so close, we’re already on the web, so the chances for exposing a service on another channel (be it a web service, or a palm interface) are far higher than before.

4) Tools like Hibernate, or Spring really make data-aware component less interesting. Off-the-shelf ORM tools weren’t that popular in the client-server days, but now they really are part of the scenario. It was different were EJBs were hype, cause “domain modelling” really sounded like “business layer”, and this sounded like “EJB” (or worse: “entity beans”) meaning finally “heavyweight mess”.

So, even if some debate is still going on, I really think that data-aware component aren’t that interesting for somebody with a java background. They might come in handy for newcomers to the java platform that can postpone learning some heavy topic in the J2EE landscape for a while, but it really sounds like a short-term choice.

Tags: JSF, OOD, RAD

New challenges for the J2EE web developer

Recent technologies such as Java Server Faces and AJAX are causing a positive earthquake in the Java web technologies arena. As far as I can see, the first victim is the Struts framework: just an year ago it was the de-facto standard for a generic J2EE web application and was backed by a good support my many different IDEs, now it looks like nobody is starting a Struts project any more.

The leading factor for establishing a prevalence of JSF over Struts has been the pursuit of productivity, which was the weak point of many web application frameworks. Overall team efficiency paid a double fee to open source standards:

• high development speed were achievable after a long training: the stack of competencies necessary to a generic web developer was definitely too high and fragmented (Servlets, Java Server Pages, tag libraries, HTTP, HTML, MVC and the framework in use).


• Integration with IDEs has never been good: first it comes the framework and then comes some form of support from the IDE, but far from being sufficient. So the standard situation is to have the IDE perform some sort of trivial task for you and then start digging in runtime case mismatch error in some XML file (I guess you know what I mean)

JSF nowadays starts straight from the IDE offering a developer a way to efficiently design web application in a way that has been forgotten for a long time (most developers I know find still more productive to manually edit web pages or tags instead of delegating it to the IDE). After a couple of projects, our experience shows that JSF impacts positively on development speed, so …goodbye Struts.

Re-enter usability
In the meanwhile, components are evolving, exploiting possibilities allowed by the AJAX technology. A new level of interactivity is possible for the web platform where it has been neglected for years (with some niche exceptions like ActiveX, Flash etc.), particularly in the enterprise software field, where you don’t have to attract users to your software (“I pay my employees to w-o-r-k, not to have a satisfactory user experience”).

Now the situation is different: in this scenario a web software can be comparable to a fat client in term of interactivity and usability. The problem is that web developers have been working without these possibilities for years (forced to choose only between combos and radio buttons) forgetting what an easy-to-use user interface should be. The move to a new paradigm has been taken only on the technology side, but doing “the same old stuff” with a new framework is only half of the job: the other half is using the new tools to produce better software.

The following months will tell if this will be achieved by improving developer’s awareness of man-machine interaction mechanism or having software analysts provide a more detailed level of specifications in the early stages of the project.

Tags: J2EE, Usability, JSF, Ajax