ClickOnce Smart Client Deployment

Want a rich browser interface for your business software? Consider another option.

One of my VAR clients needs to deploy a complex UI to over 80 end-user sites with anywhere from 3 to 100 users each. They are currently using VB6 as an ActiveX object in IE browsers for the purpose. This works well for the UI but is a real pain for security and deployment in that it involves IT people at the end-user sites, and prompts calls to the VAR’s Support line. They are considering Ajax in a more thin-client solution. To develop the UI they are considering ASP.NET, but that "might" mean setting up Windows servers at all of their end-user sites. Most of those sites, however, are running Linux servers. Do end-users really want to set up a new server just to host a single application?

The choice to run browsers was due to a perceived simplicity or elegance of using the browser as a universal client, something I’ve objected to for a long time as a general principle, but for many sites it works perfectly well. It’s not that I don’t like the RIA, what I call a BUI or Browser User Interface, but that the reality of browser deployment doesn’t match the hype that people give it. Unless people are inclined to use sophisticated UI tools, often for-fee, and spend an awful lot of time in development and cross-browser testing, it’s going to be very difficult to get that rich UI look and feel that matches original expectations. And as soon as you deploy in a brower there’s that "what if they hit the Back button" issue. A common solution is to open a new window without the "chrome", the buttons, address bar, etc. As soon as you do that though, you’re no longer technically in a "browser", you’re in a locked container. Well, as long as you’re in a locked container, why not just run a thick client?!

In my opinion, there’s absolutely nothing wrong with an end-user getting their application from their desktop rather than going to a website. For most sites, I believe we can safely assume that all end-users are running Windows workstations, and it’s better to take advantage of those than to ask a lot of sites to install a Windows server for ASP.NET deployment. Mind you, from my other blog entries about Linux and .NET, it should be evident that you don’t need Windows for ASP.NET anyway.

So rather than continue down the path where we are trying to stuff a thick-client L&F into a browser, I’m coming back and reconsidering a thick-client model, but using Click-Once (also known as Smart Client) deployment. I’ve worked on one of these projects before and it’s quite neat. Using this model you can deploy a thick client via the browser, but it doesn’t need to run in the browser like a VB6 ActiveX or a Java Applet. After the code is installed to the client PC the user can run it off of their desktop. Once the initial rollout is done you don’t need to worry about ongoing maintenance or security issues. The code can be deployed from a Linux box, no Windows server is required at the end-user site, and the client-side code automatically updates itself when the server has a new version.

From a thick client we have our choice of connectivity options. I see this as an n-tier architecture where the client connects to a middle tier, and that then connects into the DBMS. To get to the middle tier, we could use an HTTP connection to some CGI or ASP (Active Server Page, which in this case would be simply a transaction processor with no UI). Even over Linux we could use Mono or Visual Mainwin to create an ASP.NET listener which accepts inbound connections. We can also use a Web Service or .NET Remoting – again, platform independent. From the middle tier to the DBMS there are many options, depending on the OS and DBMS platforms involved. D3 sites might use FlashCONNECT as a raw pipe (again with no UI) and maybe take advantage of the SOAP connectivity built into FCv3.5. U2 sites can use UniObjects or a RedBack back end. jBASE sites have Objex. And of course my cross-platform favorite for connectivity with all platforms is mv.NET. A Windows box is still required for a couple of these but if someone needs a *nix/Linux-only connectivity solution, there are many options.

How does a VAR with many end-user sites update an environment like this? The middle-tier box at the end-user can poll the VAR’s system every day or so to see if updates are available. If so it can download the updates, load MV-side updates to the DBMS, and place the client-side updates on the end-user’s web server. Client PCs will check this server for updates and install the new client code when it’s available. The new client code will then request services with the new server-side code and… voilà! This doesn’t all have to be coded at the same time – dynamic software updates from the VAR/developer can be implemented as a "phase 2" type project.

I haven’t gone into detail about ClickOnce and Smart Client deployment, only because there is already so much information already available elsewhere. I’ve provided a few links below to kick off your education in this area. I’ll conclude simply by saying this is a viable alternative to thin-client for many applications. Before embarking on any development plan we need to connect the dots in the architecture, or in this case, just make sure that we can see a clear path from client to server and back. As described above, I see that clear path, so I wouldn’t hesitate at all to write a front-end using ClickOnce.

MSDN Magazine Return of the Rich Client
MSDN Magazine Intro to ClickOnce
MSDN Library, Another Intro to ClickOnce
MSDN Library, Configuring Trusted Publishers