GHR's online KCard repository

KCard : Web or not

The choice ... exists

Choosing if an application should be implemented as a web site (the client is a browser like IE or Mozilla and the server is a web server like Apache or IIS) or as a client/server (the client is a an executable application installed and running on the client machine which connects to the server application installed and running on the server side) isn't as straight forwards as it might seem. This KCards discusses this topic and gives some advice on how to choose a solution for a given situation.

Current trend

Clearly the current trend is to develop applications as web sites. Why exactly this has become the case isn't fully obvious. The fact is that people tend to decide that applications should be web sites without really giving it second thought. We'll try to question this attitude here and provide guidance to widen the scope of options.

Criteria for choice

In order to help decide what kind of architecture to choose some objective criteria should be used. Here are some important elements to consider:

Functional requirements: this is what does the user want the system to do from a business point of view

Technical requirements: this is what the system must provide concerning technical aspects

Deployment configurations: the structure of the network on which the system must be deployed (including client machines)

Below we detail how each of these elements can impact on the architectural choice: web or not?

Functional

The important point is to evaluate to what extent your application will require control on the flow of actions. It is usually harder to control the flow in web applications than in client/server. This is because web browsers integrate many navigation functions which aren't always too easy to remove (menu bars, tool bars, key shortcuts, ...), and this is often a browser specific tasks, meaning that you'll have to consider the different browsers. Also, the users can get annoyed to see their web browser missing their usual functions. Handling complex flows is a strength of client/server applications as the developer has available all the powerful desktop features with rich interfaces (.NET, SWING, MFC, TK, ...).

It is important to realise that choosing a web application when the user's flows of actions aren't suited will create a lot of work to try to keep control of what the user can do (avoid closing a modal dialog, avoid previous/next/etc navigation, avoid direct URL entry, ...).

Technical

Depending on the technical requirements of the application you will have more or less liberties in your technological choices. For example, presenting information is well suited to web sites whereas executing computational intensive client side functions isn't. Generally speaking, every technology can do everything if the necessary amount of effort is provided. It is not a question of possibility but rather optimality. For example it is possible to make an advanced 3D game run in a web browser (using native ActiveX components, ...), but it would certainly be a better idea to execute it as a desktop application.

More reasonably, if the technical requirements are too far from the standard possibilities of the web browsers you should avoid considering a web application. Rich clients have all access to the native platform so the possibilities aren't restricted. Web applications which require installing too many plugins/ActiveX tend to become heavy to manage and execute causing security problems.

Deployment

The simplicity of deployment is the great strength of web applications as they theoretically simply don't require anything at all. The user simply connects to the URL with his browser and he gets access to the application. This is true when only standard technologies are used (for simply presenting data for example), otherwise, the user will be required to download and install some plugins or ActiveX controls. Although this is usually quite simple, some users can be reluctant (suspicious) and also this often links the application to a given browser (because plugins and controls are often browser specific).

On the other hand, rich clients will require the client to be installed on the client machine before he can use the system. This isn't reasonable if the number of users is too large and/or not known. This is the big strength of web applications, you don't need to know the clients for them to use the system.