Return of the rich client application with .NET Framework

I have yet to meet a user who prefers to run a Web-based application instead of a rich Windows forms-based application. But I also haven’t met a systems administrator who would rather deal with the deployment and security issues that surround the Windows forms application rather than installing and supporting a Web application on a central Web server. Supporting Web applications becomes more complex every day as companies continue to block sites and disable ports in an attempt to protect their networks from intrusion. Recognizing that companies want the deployment simplicity of a Web application with the richness of a Windows forms application, Microsoft implemented functionality in the .NET Framework that supports automatic remote deployment of Windows forms applications from a Web server.

This new Windows forms deployment mechanism reduces maintenance and deployment costs without compromising security. Applications have limited system access and functionality when the code is downloaded from an external source. Just as Web applications may have different permissions when loaded from the local intranet, trusted sites, or the Internet, the .NET Framework uses these same zones to determine and configure security for Windows forms applications. Of course, for Windows forms applications to be downloaded and executed locally, the .NET Framework must already be installed. But this is becoming less of an issue now that companies are including the .NET Framework in their desktop image in order to enable rich client applications in the future. The 20-MB download required to install the framework is simple to accomplish by using Microsoft’s System Update Services for organizations with fewer than 500 systems or System Management Server for organizations with larger numbers of personal computers.

The other major inhibitor to implementing Windows forms applications is the requirement to install and support the local services that these applications require. For example, to enable SQL Database access administrators must install and support the latest MDAC (Microsoft Data Access Components) on users’ systems. But I believe that remote Web services can supply most of the services required by Windows applications. For example, Web services can be used to access remote data instead of installing local database drivers. The use of Web services to replace local application drivers will be the key to allowing corporations to rapidly move away from Web applications toward Windows applications.

Inside the firewall
Interestingly, the return to the rich client for the enterprise will happen inside the firewall just as the initial implementations of Web services have happened there. Why? Because until corporations are comfortable with the security requirements these technologies impose, they will have to go through an internal evaluation phase. In the case of Web services, companies are waiting for routing, transaction, coordination, and security standards to emerge from the WS-I. Since Windows forms applications will consume these underlying Web services, their adoption will follow and ride on Web services standards.

As internal systems are either rewritten to support Web services interfaces or wrapped with Web services interfaces using .NET, SOAP toolkits, and even EJB technology, intranet applications will consume these Web services rather than access the internal systems directly. Once these Web services become the de facto interface into systems (and this is already beginning to happen in early adopter corporations), attaching systems based on the Microsoft Office client or Windows forms applications using .NET becomes trivial. Developers get to develop rich applications quickly, users get a more robust interface, and system architects get to consolidate all access to systems and services using Web services. The current release of Microsoft Office XP provides simple consumption of Web services. Microsoft Office 2003 will include a more advanced Web services consumption model and new family members like InfoPath, which will make it simple for users to create forms-based applications that integrate with internal Web services.

Extending the reach
The initial implementation of systems that extend beyond the firewall will likely include a Web-based front end accessing a set of internal Web services that implement a service oriented application (SOA). Administrators will access the same set of business objects from inside the firewall to perform maintenance on the system using Windows forms technologies. Users inside the firewall and partners outside the firewall who “trust” the company will have the advantage of implementing even richer functionality using more advanced Windows forms technology. These advanced clients will require some reconfiguration at the client level to allow advanced Windows forms functionality like drag and drop or direct access to local resources.

But in an extranet scenario, a company’s customers or trading partners are more likely to trust the company’s applications and allow applications to be granted additional code rights. I believe that companies will create applications that can work in “trusted” and “untrusted” modes. In trusted mode, the application enables advanced User Interface features and stores settings and data locally in well-defined locations to which it has been granted access. In untrusted mode, the application uses a less sophisticated UI and stores cached settings and data in the local browser cache, but pushes all data back to the server for persistence. Users are likely to see grayed out menu items in the reduced functionality mode. Changing to trusted mode will require a local policy setting that the user may initiate from the application’s help menu.

Advanced client functionality and security
The next major advance at the operating system level will give corporations and developers additional opportunities to deploy and secure advanced Windows forms applications. When Longhorn is delivered in 2005, it will include Microsoft’s TrustBridge technology, which embeds advanced security identity into the operating system. This technology allows developers to make sure that their applications only run on authorized machines. It also allows corporations to ensure that only authorized applications or applications from authorized sources can execute on their machines. Since corporations aren’t likely to begin rolling out Longhorn until late 2005 or 2006, it will be a while before these features will be available to clients. But in the meantime, the existing benefits of Windows forms applications will continue to entice companies to consider Windows applications as the first alternative for future development.

TechRepublic originally published this article on 10 June 2003.