Welcome!

Java Authors: Greg Akers, Patrick Carey, Cloud Ventures, Martin Etmajer, Liz McMillan

Related Topics: AJAX & REA, Java

AJAX & REA: Article

Hangover Thoughts About the Web and AJAX

After five shots of straight vodka, we enjoyed a Broadway-type show, and then more drinks and food

Yesterday, we celebrated the birthday of my employee Alex in a fancy Russian restaurant. If you haven't tried it, go there - once. The party started late, and I've never seen such a variety of food on the table at the same time (they call this setup "bratskaya mogila," which means "mass grave"). After five shots of straight vodka, we enjoyed a Broadway-type show, and then more drinks and food. Anyway, this morning the last thing I wanted to do was drive to my gas station.

Last time I selected a Java Web application framework (http://java.sys-con.com/read/136518.htm) and for a second, I regretted that I hadn't implement a Web application. If I had, I could have opened a Web browser and checked on the business without leaving home. At the moment, I was pretty sure there were only two types of users that could appreciate Web applications:

  • Sober people who want to buy goods or use services offered by companies like Amazon, Ebay, Google, CNN, or Playboy
  • Drunk owners of small businesses
But after a while I thought to myself, "Not just a Web application would let me connect to my business from home." I can create a Java Swing client that will connect, say, to an RMI server. And it won't cost me a penny because RMI comes packaged with Java! Even Open Source application servers may be overkill for a small business. Besides, deploying Java clients on all of my computers can be automatic using Java Web Start (JWS) technology (this will be my answer to the zero-deployment arguments of those who like thin Web clients).

Remotely Delivering Applications with Java Web Start
Let's say I've created a front-end Java application and want to deploy it on all three of my business PCs and two of my home computers. With JWS, I can automatically deploy Java applications (not applets!) that permanently reside on these computers. Every time a user starts the application, it automatically connects to a central server, compares the local and remote versions of the application, and downloads the latest one if needed. It can also automatically download JRE. Java comes with a so-called Java Network Launching Protocol (JNLP) API, and deploying a JWS application consists of:

√ Configuring the Web server so it can support JNLP files. Free Web servers are readily available (see http://httpd.apache.org/)

√ Creating a JNLP file (it's a simple XML file describing your application)

√ Uploading the application to the Web server to a location specified in the JNLP file

√ Creating an HTML Web page that has a link to your application's JNLP file, for example <a href="GasOrder.jnlp"> Start Gas Order Program</a>

You can read more about the Java Web Start technology at http://java.sun.com/products/javawebstart/

I can have a full-featured multi-megabyte Java client that's located and launched locally on each of my computers. If once in a while I need to deploy a new release of this application, I'll just upload the new JAR to the computer that runs my Web server and all client computers will update the local version of the application automatically as soon as they see the newer JAR on the server.

Thin Clients, AJAX, and a Goat
Let me tell you an old Jewish joke.

A poor man comes to the rabbi complaining that his family has only one small room, many kids, and almost no money. The rabbi says, "Take all your money, buy a goat, and keep the goat in your room. Come back in a month."

"But, rabbi, we don't have enough space even for us," the man said

"Just do what I say," the rabbi replied.

A month later the man comes back complaining that the goat smells and breaks everything.

"Sell the goat and come back in a month," the rabbi tells him.

A month later the man comes back to the rabbi with flowers.

"Thank you, rabbi! We're so happy the goat is out, now we have more room and some money!"

So what has that story to do with thin Web clients and AJAX? Everything! Since the early nineties Visual Basic and PowerBuilder programmers have routinely created rich client applications, and if, for example, they need to repopulate a part of the screen by executing some DB query when a user types a character in a text field, they just put this query in some flavor of the ItemChangedEvent of the GUI object.

In Java it's not as simple, but still not too bad. Just register an event listener with a window control, put the db query in one of the methods of this listener, and repopulate the screen using an event-dispatching thread.

Then the Internet rush brought in plain-looking thin HTML clients (aka the goat), which had to refresh the entire page after each request. Several years later, a complex technology called AJAX came about and now people are overwhelmed with joy when they see a portion of the Web page refreshed after typing in a single character. Wow! Isn't it time to get the goat out the room and return to good old fat Java clients? I wonder why sober application architects don't see it this way.

More Stories By Yakov Fain

Yakov Fain is a co-founder of two software companies: Farata Systems and SuranceBay. He authored several technical books and lots of articles on software development. Yakov is Java Champion (https://java-champions.java.net). He leads leads Princeton Java Users Group. Two of Yakov's books will go in print this year: "Enterprise Web Development" (O'Reilly) and "Java For Kids" (No Starch Press).

Comments (17) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Web Application Architect 01/19/06 02:51:17 PM EST

Absolutely ! I have created thick client applications as a student and was a whole lot more satisfied than today when I am a professional doing XMLHttpService and thinking so hard to refresh nothing but webpages. And guess what - business says "its no rocket science" !!!.

Don Babcock 01/05/06 10:47:07 AM EST

Actually, there are several good approaches to Java client ubiquity including Java Web Start et al. These days, getting the necessary "run time" on the client required to run Java applications is no more difficult than installing a Flash player or other browser plug in. But Java, player plug-ins and frameworks are just different instances of managed code approaches. As Peter Coffee recently opined in E-Week, managed code approaches seem to be the future in terms of taming the otherwise wild environment differences that have plagued browser based clients from the introduction of the second browser candidate forward.

James Ward 01/04/06 04:54:07 PM EST

The problem with fat client Java is client ubiquity. AJAX has ubiquity. But if you want ubiquity and the power of a real fat client, check out Flex. There's a free Alpha download based on Eclipse at: http://labs.adobe.com

-James

Don Babcock 01/04/06 02:33:33 PM EST

Right ON!

What is even more amazing to me is that sober developers would even think of:

"...and if, for example, they need to repopulate a part of the screen by executing some DB query when a user types a character in a text field....."

Such dynamic updating is often touted by proponents of AJAX but never does anyone consider the server load/overhead of making a query back to the serverside DB for every keystroke event on the client. Talk about bringing the network/server to its knees! Of course the Java app would do the same thing if implemented the same way. But the "fat" client programmer is more likely to make a single query with subsequent local refinement rather than refining on the server side. The Javascript programmer in a browser environment probably won't for a number of reasons.

Aside from all that, it is very amusing indeed for those of us that date back "pre-web" (3270 screens anyone? VT100?) to watch folks that have never known any other terminal user interface than the browser get all excited about being able to do what was standard fare long ago. Your anlogy is so apt! We've been living with the limitations of the browser (another "goat" instance) for so long that when the least thing comes along to aleviate that (AJAX) folks start foaming at the mouth. HTTP itself is another "goat" instance. Look at the number of kludgey things we have to do just to maintain state. Don't get me wrong. It is ideally suited for the purpose T.B. Lee envisioned. We've just pushed it way beyond anything he ever imagined at the outset.

Personally, I'm very excited about products like Netbeans 5.0 which finally deliver a VB-like development experience (in terms of layout ease) and which can easily consume web services via WSDL (it generates all of the Java client code for you.) Writing those services is trivial using Coldfusion components (Java and Apache Axis under the covers) and if you want the freebie version check out BlueDragon by NewAtlanta. Netbeans doing Java "fat" clients coupled with Apache and BlueDragon on Linux with a Postgres or other DB back end and you have a totally low cost and very robust solution.

Vince Marco 01/04/06 01:55:43 PM EST

I've been to one of the russian parties you mention at a restaurant in Brooklyn. And yes, it is really something to experience. But we never mention the cost. It was expensive, which is why you do it once.

That is what our industry has done with browser-based web applications, especially for enterprise development. Why exactly would we build enterprise apps the same way we build consumer-oriented apps? If we were designing an enterprise development/deployment technology would we design the web as it is today (complete with browser fragmentation)? I would hope not!!

But I would tweek your original solution description a bit. I would use web service requests using JAX-RPC instead of RMI. On the one hand perhaps you are right that running an app server isn't needed for your gas station, I would counter that running AXIS on Tomcat is probably going to be not much more hassle than configuring your RMI server and the firewall. And that is where your business' technical requirements will likely grow, so XML and web services do provide value.

I agree on all your other points and would add that the next trend beyond AJAX might be to actually build RCPs (rich client programs) which perhaps embed browsers in them for the web content they need. The ultimate portal framework might actually spread itself across both the browser and server.

Mike 01/04/06 01:53:24 PM EST

I have to disagree with Sean, at least partially. I've seen at least as many PC's with Javascript disabled as I've seen without Java. As far as Costa Gino's comments are concerned, there are some valid points there, if we were going back in time 20 years. Are there no web services? No http/s tunneling? Are we missing javax.net.ssl?

Costa Gino 01/04/06 11:55:27 AM EST

after five shots of vodka I always go to the same conclusion... only a triple espresso shot will bring me back to reality... and coming back to your story I will list some of the reality's issues:
i) your runtime architecture is two-tiers, client server story... and that is it... out of how you deploy it... it runs as two-tier.

ii) a special port into the firewall has to open
today enterprises have firewalls that open and close:
a) Will you open db port right there ???
b) Will you open RMI port ???
With (b) the worse part is that there are ... ports (many)

iii) security/encryption... while SSL is just there
you have to deal with encrypting ora-net or rmi... it is not impossible ... but is not just there

iv) security reloaded
thru web/html you expose pages you see and now... if you expose your binary service to internet (*.*.*.*) how can you make sure someone is not "enjoying" the methods that were not meant to do so.
(unless you saw it with fron-end rmi-actions and back-end rmi ??? hope you didn't go that far)

v) design --
you encourage developers to "power" client-side validations... what is wrong with that... the wrong things will appear as number (iv).

The whole thing will not be really enough for pure internet apps... for intranet yes ... but for intranet you don't really need jnpl and web server ...and xml... you can drop your classes (even jvm) to a network drive... you know that.

And last but not least:
If java fat client is so good ... the next step is to pop up unix/legacy terminals thru a web browser... and then that will be the solution... black/green screens will be "web" ready hmmmm !!!
Is this what you are looking for ?

Yakov Fain 01/04/06 11:33:37 AM EST

Guys, I appreciate your feedback, but please get down to Earth. We are not solving global warming problem here. We are automating a small business, namely my gas station. I do not need to worry about clients with unknown version of JVMs. I know exactly what is installed on my 3-4 client computers.

Sean is talking about thousands of clients... Yes, the chances are that I'll become a CIO of Mobile one day. But even then, I'd better know (and control) what OS and JVMs are installed in MY COMPANY's client's machines.

Stop thinking Google or Amazon. Get real :)

Jim Amsden 01/04/06 10:24:22 AM EST

But its not quite as simple as HTML/AJAX vs. distributed Java fat-client applications. Yes, it is now possible to reduce the cost of ownership of Java client applications through automatic updates. But this gets more complicated when there are a suite of related applications that need to be updated as a group.

But the real problem is that distributed client/server programs have to be designed differently than traditional fat-client applications. Distribution has to be factored into how the user interacts with the program, when fields are refreshed, what data is cached in the client and when, how tolerant the application is to stale data, etc. AJAX makes you think about these things because you can't build an application without it. Java can do it too, but you have to deal with the distribution patterns yourself.

Sean 01/04/06 10:04:32 AM EST

In the real world where you have thousands of clients with all sorts of different setups on their PCs, the browser is the common element you can depend on. Some PCs may have java, some may not; some have the wrong version, and it's not like java is all that portable between versions. No, AJAX avoids the issues of java and plugins, providing a solution you can deliver to the most people.

Mike 01/04/06 09:52:23 AM EST

You know, we are supposed to be able to manipulate the DOM from an applet just like you can from Javascript, its been there in one form or another since JDK 1.3. I say supposed to be because I haven't been able to get it to work right, and the documentation, as usual is lacking. So maybe we all need to start moving some votes on the Java bug tracker?

Christian 01/04/06 07:07:57 AM EST

I'm releaved to see there are people that have the guts to see through the frail hype of AJAX.
In many rich web clients JWS will be the best choice. The richer the client the better.
If you are doing a client for an intra net then there really should be no question about it (there are of course special cases and exceptions, as always...).

Marius 01/02/06 05:03:55 PM EST

The problem with your thought is Microsoft.

As long as most users are using MS Windows, which often hasn't Web start or a recent java version installed, it is easier for users to use a web application.

Installation of web start might even require administrator privileges which the user probably doesn't have.

skyanchor 12/29/05 07:25:24 PM EST

Though it may have been written with a hangover, this is one of the most clear-headed articles I've read in quite a while. I would just add that in the mid-90's Delphi additionally brought custom visual components and visual form inheritance to rich client development.

news desk 12/26/05 11:09:31 AM EST

Yesterday, we celebrated the birthday of my employee Alex in a fancy Russian restaurant. If you haven't tried it, go there - once. The party started late, and I've never seen such a variety of food on the table at the same time (they call this setup 'bratskaya mogila,' which means 'mass grave'). After five shots of straight vodka, we enjoyed a Broadway-type show, and then more drinks and food. Anyway, this morning the last thing I wanted to do was drive to my gas station.

news desk 12/26/05 10:33:53 AM EST

Yesterday, we celebrated the birthday of my employee Alex in a fancy Russian restaurant. If you haven't tried it, go there - once. The party started late, and I've never seen such a variety of food on the table at the same time (they call this setup 'bratskaya mogila,' which means 'mass grave'). After five shots of straight vodka, we enjoyed a Broadway-type show, and then more drinks and food. Anyway, this morning the last thing I wanted to do was drive to my gas station.

JDJ News Desk 12/25/05 10:34:59 PM EST

Yesterday, we celebrated the birthday of my employee Alex in a fancy Russian restaurant. If you haven't tried it, go there - once. The party started late, and I've never seen such a variety of food on the table at the same time (they call this setup 'bratskaya mogila,' which means 'mass grave'). After five shots of straight vodka, we enjoyed a Broadway-type show, and then more drinks and food. Anyway, this morning the last thing I wanted to do was drive to my gas station.