A software architecture toolset for choosing the right type of Client Application

Introduction

The article deals with an important question, one that raises a lot of debate in the .NET software architecture world.

What to choose: "Web-Application" or "Desktop-Application"? Rich-Internet-Application or a Smart-Client?

The reason why this question is asked so frequently recently, is that both technologies are getting closer and closer and when the distinctions becomes fuzzy the decision is harder to make. For example, Smart client introduces smart deployment and diminishes one of the biggest cons of Desktop-Application. With Ajax, Web-Applications run faster and with enhanced user experience.

Before we get started it is important to say right here and now that the define question above must always depends on the business problem.

It will be an obscene act for a developer or architect to choose a technology based on a whim. Technology should not be chosen on stuffy professionalism either. Many companies choose technology because this is what the current developer knows and good at. Choosing the right application type is crucial in many businesses. The end users and the business problem on hand, are the ones who should take the lead in the decision making.

This article does not deal with a certain business issue. It discusses the common pros and cons of each methodology.

The Dialog

I choose to face with this question in a dialog form. The Dialog is conduct between two software architectures.

Socrates: a Web-Application advocate and

Plato: a Desktop-Application advocate.

The dialog format allows me to not take a stand. In a matter of fact I don't have a stand. I think both technologies are great and when there is a need to choose one of them it should be according to the business problem.

You are most welcome to join to their (imaginary) debate held in modern Greece in one of the Tech-Ed .Net seminars.

Socrates:
… But Plato, your claim about the needs for constant software upgrades only strengthens my argument that Web-Applications are the best technology. In a Web-Application the application is actually located on a remote server which you can upgrade when ever it's needed and it reflects to your users online. In other words, when all the code is in one place everyone sees the latest release.

Plato:
Well, with ClickOnce technology a Windows-Form-Application can be deployed and launch from the Web. With this type of technology software upgrades have never been easier to maintain.

Socrates:
Oh, I heard about what it is capable of, but isn't it too cumbersome to accomplish? You do need to make all the assemblies strongly named and the amount of folders and files it creates on the web server is quite…well… cumbersome. Moreover, who wants to install a Desktop-Application on his hard drive if he does not have to?

Plato:
Well, I guess this technology will be improved by the Redmond fox in the future. Right now, the user can choose between offline and online executions. In both modes the application is installed on the machine. The difference is that in offline mode the application can be jump started and get updated from the desktop while in online mode it can be run only from the web link as before. Please also know that ClickOnce is not the only solution. A "home made" solution like using a Web-Service that the Desktop-Application communicates with, checks and install updates are easy to develop.

Socrates:
So you are basically saying that in online mode, which is closest to running a Web-Application, the application is reinstalled again and again in each run. What if it is a big application in term of Mega bytes? Well, my dear Plato I rest my case.

Plato:
No, you haven't, because there is some kind of caching mechanism that improves this behavior. I guess, the .Net Framework only downloads the required files.

Socrates:
Hmmm…, .NET Framework you said. Well do I smell a software perquisite in the air?

Plato:
You do smell well, but do understand that the user must not have the .NET framework on his computer or must preinstall it manually. The deployed ClickOnce application can be easily defined to support the installation of the .NET Framework (bootstrapper). Dear Socrates, as you well know Web-Applications commonly require ActiveX installations? Those requirements often scare users because they are commonly causing the web browsers to display intimidating security.



Socrates:
Well, you are right; today's web browsers do make us lots of headaches. But, Windows firewalls often do the same for Desktop-Applications.

Plato:
In Desktop-Applications as opposed to web-browser the application has rights that are granted from the logon user. It can access system data like IP Address, Registry, Files, Windows Shell integration etc. In a script mode the Web-Application is very limited and the ActiveX technology is one of the last resorts. Web-Applications cannot leverage local resources like CPU or installed software either. Moreover, isn't true that ActiveX is also being used in Web-Applications to enhance graphic capabilities like Charts, Maps etc.

Socrates:
Well, it depends on what the Web-Application is obligated to do. But, yes it is often use for more complex and some kind of fancier UI controls.

Plato:
I guess you will also agree that Web-Application will never be capable to support GUI and visualization functionalities like Desktop-Application. For example, the user interface must travel back and forward across the web in order to be refreshed.

Socrates:
I wouldn't say always. AJAX, for example enhances the UI capabilities.

Plato:
AJAX also added tons of client-side script code and that hurts performance and harms the user experience. With AJAX, Web-Applications stop being a thin application and start to get fat. Speaking of scripts, isn't true that debugging capabilities of client and server side scripts languages like VB and Java script are impossible. Isn't also true that developing in this kind of script language is klutzy?

Socrates:
With today's ASP.NET technology, server code (code behind) can be written in a high level language (any .NET aware language) that can be of course debugged. As for client and server side scripts I am afraid you are right.

Plato, with you permission I would like to talk about application availability. As you recall, in Web-Application the application is available and can be access from anywhere without installing anything on the client machine. For example, Gmail is a web-based Email application. You can enter to your Inbox no matter where you are. In case, you are entering an Internet-Café you surly be permitted to enter to Gmail but not to install any application on the machine.



Plato:
Yes, I see your point. But what if I am in my home or at the office and I want to see my Emails but the Gmail server is down or I have temporarily lost my Internet connection. I will not be able to see my Emails right? Web-Application must be connected to the server all the time. In other words Desktop-Applications offer better offline and caching capabilities. There is no need to waste time waiting for screens to refresh or networks to become available



As opposed to:



Socrates:
Well, if you need smart caching and offline capabilities you are right. Another thing that I would like to mention is a cross-platform capability. If your Desktop-Application is targeting to a world wide use will you be able to install it on Linux and on Windows OS. Even if you have decided to support only Windows OS family you will still need to support and test your application on lots of versions like: 98/ME/NT/2000/2003/XP/Vista.

Not including sub versions like Home and professional editions. You will soon notice that the above OS supports different APIs and acts differently. In case of a Web-Application you are running within a well tested application (like IE) that was already tested on those OS. Web Browsers are also committed to standards like HTML and Java scripts interpretation. Therefore, as long as you stick to standards you will have no problems.

Plato:
At the beginning, you have almost convinced me, but then I have figured there are a lot of web browsers vendors and lots of web browser versions. Also there are a lot of technologist like ActiveX and Flash that will not work on Mac web browsers. Nevertheless, you are right if the Web-Application is simply enough will be easier to support world wide users.

Socrates:
Well, working with a markup language like HTML also holds lots of simplicity and flexibility capabilities.

Plato:
It is true! But at the same time it is also very limited. With XAML markup language, Desktop-Applications also enjoy the flexibility like HTML plus much more enhanced UI capabilities.

Socrates:
OK, Plato we are not even close to end this debate, but I do need to go. I have a meeting with Xenophon at the local SPA.

Plato:
Adio! Socrates. Send my regards.

What does the future hold?

It is hard to say what to future holds. One should be a profit to tell. My guess is that we are going to face with the article question for a long time, at least for the near future.

Looking at brand new developing styles like SmartClient and AJAX, makes you think that no new revolutionary progress have been made in the last years.

"…AJAX is not a new programming language, but a new way to use existing standards." (http://www.w3schools.com/ajax/default.asp)

"…Smart client isn't a technology, and it isn't any specific architecture. It is a style of application that combines the best of both Desktop-Applications and Web-Applications." (http://msdn.microsoft.com/smartclient/community/scfaq/default.aspx)

Some of the common use technologies are really very old:

• ActiveX in 1990 (http://en.wikipedia.org/wiki/ActiveX)
• VB – 1991 (http://www.startvbdotnet.com/dotnet/vb.aspx)
• MFC -1992
• In 1994 the very earlier version of HTML was introduced (http://www.w3.org/MarkUp/historical).
• JavaScript in 1995 (http://www.oreillynet.com/pub/a/javascript/2001/04/06/js_history.html)
• Flash - In 1996

Smart-Client vs. Rich-Internet-Application (RIA)

"Rich Internet applications (RIA) are web applications that have the features and functionality of traditional desktop applications. RIAs typically transfer the processing necessary for the user interface to the web client but keep the bulk of the data (i.e. maintaining the state of the program, the data etc) back on the application server. (http://en.wikipedia.org/wiki/Rich_Internet_application)

Rich Internet Applications are already here. Google is one of the world leaders in Rich-Internet-Application. Here are some of examples: Gmail, Google Calendar and Google Docs and Spreadsheets.

Rich Internet applications characteristics:

• Run in a web browser
• Typically much more responsive than a standard web applications
• Richer UI
• Has a look and feel of a desktop application

Smart-Client characteristics:

• Are delivered over the web
• Do not require installation
• Automatically update without user action

Trends

• The complexity of applications is increasing
• Connectivity and Network awareness- Different application types to the same source of data. Connect to the data from Mobile, Desktop application at the office adn over the web when out of the office
• A2A – similar to B2B only with application that can talk with each other by using standards like Bluetooth for Mobile devices.
• Save data online - Google Bookmarks for example and MS Messenger keep the user information like Favorits in the web. This allows the user to see the stored data from different PCs.
• Application recovery – return to previous state no matter what happened to the last application run.

Summary

Choosing the right technology must be anchor to the business problem on hand.

You would not develop a diagram drawing application like MS-Visio as a Web-Application as you would not choose a Desktop-Application for Amazon book store.

The article describes some of the Cons and Pros of each technology. Knowing them is a good start for a decision making.

Further reading

• Smart Client FAQ
• What is a Smart Client anyway?
• Ajax.org
• Rich Internet Applications: Design, Measurement, and Management Challenges, Keynote Systems, 2006 (PDF)