RIA Developer's Journal

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.