BitsAndBuzz

Software technologists tend to learn by oscillating. We never arrive directly at the right solution; we just come closer to it by going back and forth. We always think (or like to think) that our current solution is correct; only to realize, some years later, that we overshot and need to take a few steps back. The evolution of the software application model is a great example of this syndrome. Every technologist knows about the three main application model phases—Mainframe, Client/Server, and Web [1.0]—and many of them think they know what the next phase will be. In fact, two models are currently being promoted. In order to better understand the current trend, it is important to first understand the three original model phases.

1) Mainframe

The first application model was the mainframe;  the client was simply a screen (typically green) and a keyboard that could display and send characters back and forth through a network. The server had all the definitions of the screens (i.e. User Interface), application logic, and data, and was communicating with the client by sending characters (which represented the UI and data) back and forth.

This approach had the benefit of being relatively simple, cost effective to scale, and was easy to manage because the application could be centrally managed. The limitation was obviously that the client’s lack of richness limited the type of application that could be offered. For example, a Google Map on a green screen would have been a challenge to implement.

2) Client/Server

The second application model came with the popularization of personal computers by IBM, Microsoft, and Apple. Now that users were able to have actual processing and display power on their desktop, the application UI and the logic could reside on the client side, while the data could reside either locally or remotely on servers. The application UI and logic were usually packaged and optimized (i.e. compiled), and had to be physically installed on the client side. When the user needed a new application or a new version of the application, s/he had to explicitly acquire and install the new application or upgrade package. In this scenario, the server’s responsibility was to synchronize data.

The benefit was that new applications could take advantage of Moore’s law on both ends of the network, which consequently allowed for a wide variety of applications, such as word processing, CAD/3D tools, and games, just to name a few.

The downside was that the application life cycle (e.g., installs and upgrades) required the user’s intervention, making some application scenarios relatively expensive to deploy and manage.

3) Web

Then came the Web; at first, it was mostly used to access (i.e. browse) content. However, through its simplicity and network-centric characteristics, it quickly became a very effective way to deploy networked-based applications. The model was similar to that of the Mainframe, where the server sent UI instructions to the client. But this time, the client could do much more; although still relatively primitive, the Web model had some extended UI elements that included image, text, and input fields, and even allowed the payload to carry some logic (i.e. JavaScript) that would be interpreted and run on the client side.

Although not as rich as the Client/Server application, the benefits of the Web were unparalleled when it came to deploying applications over the network. The fact that the server had complete control of all aspects of the application—UI, logic, and data—made this application model a genuine standard for Internet applications.

However, there were two disadvantages to this model. First, the UI primitives were not as rich as its Client/Server counterpart, making the appearance and interaction of Web applications less competitive. Luckily, the Web had a very inclusive architecture, and allowed plug-ins vendors, such as Sun and Adobe, to extend the Web primitives with capabilities such as video and audio. Second, the application granularity was the screen (i.e. page), meaning that each user interaction required a screen refresh that updated the UI, logic, and data simultaneously. While the single screen model was easy for developers to understand, it made highly interactive applications quite a challenge to build, and often resulted in a poor or confusing user interface experience.

4) ???

So, where are we now? What is the fourth phase? Currently, there are two possible directions: the Compiled Web and the Interpreted Web.

 

4.1) Compiled Web

The Compiled Web model is, in a way, the Client/Server model inside a browser. First introduced by Java, with Applets, and now being revived with Adobe Flash/Flex, the concept is to compile all the application user interfaces and logic into one or more packages (.jar for Java, .swf/.swc for Flash) that will be downloaded and run by the client; this time, inside a Web browser. This model is often based on browser plug-ins such as Sun Java or Adobe Flash, and usually relies on typed and object-oriented languages like Java or ActionScript 3. Such applications communicate mainly with servers, as the Client/Server did, in order to synchronize data or to call Web services.

The advantage of this approach is that it offers Client/Server developers a very familiar application model while allowing the end-result application to leverage some of the Web deployment characteristics. The other significant benefit is that browser plug-ins such as Java, Flash, and Microsoft SilverLight extend a browser’s capabilities with video, audio, 2D/3D apis, and threading (for Java/JavaFX), allowing applications to take full advantage of the client’s computer processing and display power.

However, the Compiled Web model does not fully take advantage of the dynamic characteristics of the Web. By fixing the UI definition and behavior at the time of compilation (i.e., design time), the Compiled Web model removes the server’s ability to fully participate in the UI generation and orchestration, which could be limit many Web applications, such as model-driven applications. Also, this packaging phase reduces the application’s life-cycle flexibility since any update or enhancement will require a large part of the application, if not all of it, to be rebuilt and redeployed. While modularization is possible, modules have to be carefully thought-out; once designed, they are relatively fixed.

There is also a misunderstanding about performance, which asserts that because a compiled code runs faster than an interpreted code, a Compiled Web application performance must be greater than a regular Interpreted Web application. While theoretically correct, this reasoning does not take into consideration the on-demand nature of the Web, whose applications are expected to be instantly accessible from several entry points. The compiled approach is not suitable for this requirement because it requires the entire application (or large parts of it) to be downloaded before anything can be displayed to the user. This is retrograde from the Web application model, which allows a more organic interaction in which only the required resources for a specific interface (i.e. a screen) need to be downloaded. As a result of this limitation, loading progress animation has become a very common experience for many Compiled Web-style applications.

4.2) Interpreted Web

On the other hand, the Interpreted Web, is just the natural evolution of the traditional Web application model with an extended set of user interface constructs and capabilities, as well as an asynchronous way (i.e., AJAX) to send requests and to recover resources over the network without requiring a screen refresh. This AJAX capability, coupled with the complete dynamicity of Web technologies, where any part of the application such as UI structure, UI style, logic, and data can be dynamically updated, offering limitless architecture possibilities.

This approach still leverages all the benefits of the Web model, while extending the user interface richness and breaking down the page granularity to virtually any piece (UI, logic, and data) of the application. This allows a wide spectrum of application styles, from a single page style (Google Docs) to a page-based style with highly interactive components (Facebook or SalesForce.com). By allowing the server to be a complete part of all aspects of the application (UI, logic, and data), this model is an ideal approach for model-driven applications that require the user interface to be dynamically generated from the server, as well as large suites of applications such as Google Apps or Facebook. Also, the extended granularity offers unparalleled application life cycle agility. Upgrading or enhancing an application only requires updating of the necessary pages or resources of the application, and the user will only download these modified resources when he requests the updated interface.

The downside to all of this is that browsers still have a limited set of UI capabilities. For example, video and audio still require third party plug-ins (which usually rely on a different application model); and 2D/drawing apis are still cumbersome (no DOM for Canvas and not-as-HTML-friendly SVG). Thanks to the Web-inclusive architecture, it is relatively easy to embed plug-in components for these advanced functionalities (i.e. charting, video, audio, and drawing), although they do not always blend very well with the Web model.

Now, to add some confusion to the mix, it is possible to implement Compiled Web framework with interpreted technologies and vice versa. Google GWT is a perfect example of such hybrid model by exposing a Swing API to the developer and deploying HTML/Javascript code. The reverse can also be done in Java/JavaFx by interpreting XML UI elements (e.g., Nexaweb XAL technology) and using a scripting language like Groovy or JavaScript/Rhino. Interestingly enough, SilverLight is already a hybrid of the two models because it supports dynamic and compiled languages via the .Net CLR technologies and allows XAML to be dynamically evaluated. Unfortunately, it is harder to have an Interpreted Web architecture using Flash technology since, for business and performance reasons, Adobe seems to have rejected the interpreted model by making most of their technologies—ActionScript 3, Flex, FXG—compiled centric: no evaluations and no runtime MXML (you can build your own, but you are up for a ride). (see also: Why FXG is not based on SVG).

Which one?

So, which one is better? Which one should you base your application on? Well, it depends on what type of application you want to build and what skills you have available.

If you want to make a desktop application and deploy it over the web, the Compiled Web approach might be a good solution. This is also true if your engineering team has strong Client/Server development expertise (i.e. Windows MFC, Swing, etc.). Using a modern Compiled Web framework, such as Flash/Flex, might be a good path, because Open Web (i.e. Html/CSS/Javascript/SVG/Canvas) development could be frustrating for non-Web developers.

On the other hand, if you want to do a rich Web application that leverages as many Web characteristics as possible, and most of the logic needs to be on the server side, the Interpreted Web approach will give you unparalleled flexibility and functionality.

The good news is that if you choose the Interpreted Web model as your main framework, you can always add compiled-based components. YouTube or SalesForce.com are good example of such an approach. However, the reverse is much harder, if not impossible.

This was a relatively long post, but was the reflection of many years working on the subject.

If you are in the midst of designing your rich Web application architecture and would like third-party validation and advice, I would be more than happy to offer an hour or so (free of charge) over the phone (i.e. Skype). Just email me at jeremy.chone@gmail.com

Posted: Thursday, April 30th, 2009
Tags: Architecture.
Actions: RSS 2.0 feed. Both comments and pings are currently closed.