.NET Musings

This is part one of a two part post discussing the architectural implication of Smart Client vs Thin Client deployment models. Both of these posts will appear together as a single article on the web site NPlus1.org, a site dedicated to the architectural community.

In my previous post, we discussed scenarios that are mostly clear cut. This post will focus on those scenarios where there are additional factors to consider.

The Not So Easy Choices

If your application doesn’t fit into any of the above scenarios, how do you (as an architect) recommend on model over the other? Keeping in mind that applications are only as successful as their adoption, my philosophy is to lead with the smart client approach (WinForms or WPF) until I encounter a factor that rules it out. The factors that must be investigated include deployment issues (verifying the correct .Net Framework is installed, initial application deployment, application updates), Security, and Data.

Deployment Issues

.Net Framework Install

Whereas the developer can assume the user will have at least one browser installed on their computer (maybe not the correct manufacturer or version, but that’s a topic for another article), this is not true for the .Net framework. The correct framework is available through individual download, windows update, installed through ClickOnce, or via a bootstrapper in an MSI package for your application. This typically is not a blocker.

Initial Installation

If your application is going to require any COM components (or anything that requires the registration), you are going down a perilous path that leads straight to DLL Hell. If your application can NOT be developed entirely in managed code (along with any third part components such as reporting packages), then the application is not a candidate for smart client deployment.

If your application is completely managed code, the initial installation of the application can be accomplished through Click Once, MSI, or xcopy deployment through the company’s network via various network tools. However, installation needs to be more than just getting the correct bits onto the users’ computers. The application also has to be easy to launch (“Where’s that thing I click?”). Both ClickOnce and MSI packages can add the launch icon to the correct locations (typically the Windows Desktop and the Start menu).

Application Updates

The initial installation is by far not the largest deployment hurdle. It is managing the deployment of the application updates that proved to be the downfall of the Client Server applications. This is where MSI loses. However, as long as the application is still 100% managed code, ClickOnce and the various network utilities will handle this wonderfully. There are instances where it makes sense to roll your own update mechanism, but the factors to consider go beyond the scope of this article. (that will be the topic for another article).

Security

When developing thin client applications, the security focus is on such things as SQL injections and other hacking techniques. Physical security is not usually a concern, since the datacenters are typically well protected.

With smart clients, the application (and potentially a copy of the data) is installed on the desktop. How do you store the connection string? What about reverse engineering of the application? What about any data stored on the computer? Laptop thefts are more common, not for their hardware, but for the data and/or passwords they contain. While this is not an article on security, and all such items need to go through you corporate security group, here are some commonly used techniques to handle these issue. If your security personnel do not approve, or the security implications are deemed too much scope, than I would recommend developing a thin client.

Connection Strings

A common technique is to not store the connection string on the client computer. The client will contact a web service that in turn returns the connection string to the client after some form of authentication. The other (simpler, but arguably less secure) method is to encrypt the connection string in the application’s configuration file. This then becomes an issue of key storage.

Preventing Reverse Engineering

.Net code can be easily reverse engineered (just download Reflector and open up some of your assemblies). The solution to this is a technique called obfuscation. There are several commercial products that will handle this for you, but this adds an additional level to the deployment of updated assemblies. If you have multiple assemblies in your application, they either need to be redeployed in their entirety, or you need to get a product that can handle differential obfuscation.

Data Security

If your application is occasionally connected, and you are storing data on the user’s computer, data security is a concern. You have to be using a local data storage solution that supports encryption (such as most versions of SQL Server). Storing sensitive data in raw XML is certainly not a viable solution, and will get you on the 6:00 news in a hurry!

Data

If the application will be storing data locally (such as an occasionally connected application), then there are several factors to contend with. How do you merge the local data back into the main data store? What concurrency model is to be used? There are several products that will handle merge/replication; it’s a matter of picking the best one for your application (or at least one that your corporate policies will support and meets the requirements of your application).

A tougher question is how to handle concurrency issues. Of course this isn’t a smart client vs. thin client problem; this is a problem with any application that has data and more than one user. However, it is magnified when there is more than one data store as in the case of occasionally connected users. For the purposes of this discussion, I will simply state make sure there is only one System of Record (i.e. avoid master-master replication schemes), and pick a tool that has merge replication built in.

Summary

So, where do we end up? The one common thread running through all of these scenarios is (to borrow an oft-quoted term by a good friend of mine, Leon Gersing) “Critical Thought”. The deployment decision must be carefully examined to make sure that you business application is providing the best user experience possible while also covering all of the “ilities” necessary for long term success.