Chances are, if you are an software architect and need to make applications available over the network, you are asking yourself what client technology to use. In this article, I will try to list the solutions used previously and then elaborate on the solutions available today.
History
At the beginning, applications were solely deployed on a big machine. Everything happened there. To use the software, you needed to use a poor user interface aptly named a passive terminal. It output text: if you were lucky, you had colors! It was the one tier era.
The next phase started when the cost of micro-computers went down. Every enterprise wanted to have some. The software industry evolved and moved the applications from the mainframe to the individual computers. It is a move that is still not finished - some companies still have mainframes - but the proof of this is that not many enterprises are migrating from clustered servers to mainframes. Data stayed on the server though: this was the 2-tier era.
Anyway, as software began to flourish on the user’s computer, so did the problems. At first, it was only technical problems: since hard drive space was limited, software vendors toyed with the ability to share libraries among applications. Thus started the infamous DLL hell that sometimes persist today. But the real problems appeared when the number of machines grew exponentially: the deployment of an application on 1'000 or 10'000 computers became a project in itself.
These disadvantages (and the associated growing costs) made some people think lateraly. What if the software was installed on a single node and the user accessed this node through the network? This could solve both the DLL hell and the deployment costs problems. Some devious minds even had the technology to do that just at hand: HTML over HTTP. It was the 3-tier era and we still live in it. Even though you can always add more tier, it doesn’t change the fundamental paradigm.
Limits of the HTML over HTTP model
HTML and HTTP have fundamental flaws for use as an application interface, though. HTML’s real motivation is to navigate through a text document’s maze and HTTP’s only goal is to transmit HTML over the network.
Thus, use of these technologies in ways that were not originally intended now show their limits:
- browsers are not compatible. That’s sometimes the case not only between two versions of the same browsers but between the same version on two different operating systems
- the complexity and the costs are transferred from the deployment phase to the development phase. A JEE developer have to know the following stack: Java, Servlet, JSP, HTML, JavaScript and CSS, just to name a few
- the document centric model of HTTP forces the reload of the entire page, even if just a few elements have changed. The network speed becomes the critical factor
- users complain about the limited user interactions. Ever tried to filter a combo box in pure HTML?
With the help of Microsoft, AJAX * came to the rescue of the last two problems: AJAX let you update part(s) of the page without a complete reload and give you access to widgets that propose professional user interaction.
Unfortunately, AJAX aggravates the first two problems: what is the support of this new technology among the browsers?
Creating the XMLHTTPRequest is a matter or whether the browser is Internet Explorer or not.
Even worse, the technology stacks one more component now.
You could argue that using an AJAX framework can ease development but the problem stays the same, one more component whatsoever.
For those of you that may think HTML 5 as the panacea, I will respectfully remind you that the HTML 4 specification is dated 1999 and that the HTML 5 specification is still in draft: 10 years in our trade is likely to kill any good idea before its birth. But that’s a post for another time; back on track, please.
Typology
That said, today’s is flooded with plenty of Rich Client technologies aimed at enhancing or replacing our familiar technologies. I will present here only technologies that keep the single point of deployment paradigm (clustering excluded), meaning applications should be able to update (or be updated) quickly and painlessly.
The following picture is a shot at classifying presentation layer technologies in the Java ecosystem. Notice that some may be used in other ecosystems too since they are technology neutral from a server point of view.
Words of advice:
- this typology tries to dispatch very different technologies into cleanly separate categories. As such, some are more artificial than others. Moreover, some techs may legitimately belong to more than one category
- don’t hold it against me if your favorite tech isn’t shown above. I have not a complete knowledge of a very moving and innovating landscape
Evolutions
On the right wing, we see technologies that represent a real evolution of the client. They all run over a virtual machine installed on the client computer.
From there, the main difference is whether the application is displayed through the browser or directly. The former are still somehow tied to the browser, such as Java Applets **, Flex that use the Flash plugin or even Firefox plugins. Each of them has a standalone equivalent.
The latter represent a new frame of mind where applications are clearly distinct from sites and are available separately from the tool used to browse sites. Apart from Air that is inspired by the JVM but with higher level considerations, two technologies are worth noting:
- The JNLP file format, which is an external deployment descriptor available on the web for any Java application. Implementations include Java Web Start, Sun’s solution and an OpenSource alternative which is no more maintained, NetX. Both have the ability to read the JNLP in order to download, deploy and run the described application. They both use the JVM
- Eclipse Rich Client Platform, which is a basis to create applications upon. Such applications can have the ability to update themselves virtually for free: only declarative use of such a feature is needed. Eclipse RCP also uses a JVM to run
Enhancement
On the left wing, we have technologies that want to enhance the current HTTP - HTML - DOM - ECMAScript - CSS stack. This branch is dependent on the browser’s implementation of the previous technologies specifications, especially ECMAScript. The main subdivision criterion is how the files are generated:
- the first branch manipulates DOM on the client side. This is the domain of ECMAScript with products such as jQuery, Dojo and others.
- the second branch creates HTML and JavaScript on the server side at runtime. Those frameworks are nowadays clearly component oriented and such is the realm of JSF
- the third branch also creates HTML and JavaScript on the server side but at compile time. This is the original approach of GWT
Choice criteria
With all these technologies available, I think now is the right time for an enterprise to consider what rich client tech to use since the HTML paradigm is at an end and there are plenty (too much?) to choose from.
Five or so years ago, when doing Java development, you automatically choosed Struts. Nowadays, the question needs to be asked. But first, what criteria shall be used in order to evaluate the solution(s)? IMHO, these criteria shouldn’t all be technically oriented. The provider or the licence type are equally important because the durability is at the heart of the matter: some IS are built to last with 10 years in mind! The solution chosen will become the company’s standard, so it is a matter of investment and nobody likes wasting money, shareholders even less.
* In the rest of the post, AJAX will be the catchall word for both true AJAX and AJAJ (with JSON instead of XML)
** It it my personal opinion that applets, despite technical drawbacks, were years ahead of their time and for this reason, didn’t catch on. The Apache Pivot project is a framework built upon Applet