In the past few years, we’ve witnessed the mass migration of software development teams from the Windows development platform to Web development technologies, including HTML, ASP, JSP, DHTML, ColdFusion, and PHP. Until now, the benefits of the Web development were beyond repudiation.
Recently, Microsoft’s .NET platform released a technology called No Touch Deployment (NTD). NTD could well start a mass exodus from Web development back to Windows Forms development—NTD applications can run over the Internet without touching the user’s machine. It offers all the benefits of Web development without requiring any of the compromises on user interface design and without any of the difficulties associated with Web development. The pendulum is swinging back toward Microsoft, and your next project might well be ideally suited for NTD.
Web development benefits
Before launching into the intricacies of NTD, let’s discuss the benefits and drawbacks of the Web deployment model. There are primarily two benefits: cost of deployment and the target machine.
Cost of deployment
Deploying Windows applications is a relatively expensive endeavor. The cost of initial installation, subsequent upgrades, and general administration of client machines is a primary business driver for opting for a Web application.
Target machine unaffected
The Web deployment model enables a thin client, consisting of a browser only. This is strategically advantageous because it allows users to execute the application without installing any software. Since the target machine is not touched, users feel comfortable running applications they might otherwise not trust. It reduces the amount of expertise needed to successfully run an application.
A third benefit, which existed before the browser wars, is platform independent development. Proprietary technologies such as HTML Extensions, COM, ActiveX, and XML Data Islands have largely undermined this benefit. The truth is, unless your site comprises HTML only, then you are likely targeting a specific browser, with the hopes that other browsers will support your Web application.
Web development drawbacks
The benefits derived of Web applications do not come without a price. In fact, there are distinct disadvantages that accompany Web applications, such as a limited user experience. It would be difficult to argue that the Web provides a richer user interface as opposed to Windows applications. The widgets available on the Web are actually severely limited as compared to their Windows counterparts. Slider controls, spin boxes, and color boxes are easily implemented in Windows applications, but not in Web applications.
No touch deployment
One year ago, I wouldn’t involve myself in a project unless it was Web-based (e.g., HTML, ASP.NET, etc.). Today I’m involved in several projects that are Windows Forms applications. The users are Internet users, and it uses the NTD technology. Some will likely draw comparisons to Java Web Start, and they are similar in some respects; however, NTD is more powerful insofar as it offers completely configurable code access security (CAS).
Code access security
According to Microsoft, CAS is “a mechanism provided by the common language runtime whereby managed code is granted permissions by security policy and these permissions are enforced, limiting the operations that the code will be allowed to perform.”
Understanding CAS is necessary to derive the full benefits of NTD, since an application deployed over the Internet needs the necessary permissions on the client machine to execute correctly.
No touch deployment example
Let’s take a look at an example where the executable resides on a Web server on the local machine. CAS grants full permissions to any executable residing on the local machine. This isn’t the case if the executable is downloaded from another machine. So when you deploy your application, you’ll deploy to the http://localhost.
Suppose CodeConference.com wants to allow users to register for a conference using a Windows app. For now the application will not do anything useful nor will it communicate back with the server, because this would require a Web service. The application will simply bring up a screen with a button, which when pushed, says “Hello.” Once the application has been compiled, the executable CodeConferenceRegistration.exe should be copied to an IIS server. Users can then browse to the executable using Internet Explorer using http://localhost/CodeConferenceRegistration.exe.
Internet Explorer has a hook that recognizes the .exe extension, the executable is downloaded over http, and the common language runtime executes the application. Of course, CAS may restrict execution unless configured correctly. This example is trivial, though, because you’ve placed the executable on the same machine.
There will be skeptics
Inevitably there will be skeptics who will claim that this deployment scheme has been tried with Java Applets or Java Web Start and that the technology was not successful in that it didn’t capture much market share. These skeptics would be correct to raise such concerns, however the conditions under which the Java Applets emerged couldn’t be less similar to the conditions of today.
Applets weren’t popular since they required higher bandwidth, which was not as prevalent as it is today, when many users have broadband at home. Furthermore, the technology used to communicate between client and server was not as elegant as that of Web services. Another drawback of NTD is that it requires the .NET Framework to be installed on the client machine. And since .NET applications need to be run through the common language runtime, at this juncture most client machines don’t have the .NET Framework installed. But as time passes, this will change.