Smart Client Application Model and the .NET Framework 1.1

Introduction

For the past five years, software developers targeting the corporate environment have faced a difficult tradeoff when deciding between the browser-based, thin client application model and its rich client counterpart.

The browser-based application is easy to install and maintain, can target many desktops, and has no impact on the state of the client computer. Yet in spite of these advantages, the browser-based model is far from perfect. Rich client applications provide a richer user interface (UI) along with access to the local disk and local application programming interfaces (APIs), further empowering the developer and resulting in a more productive user experience. Because they run locally on the client computer, rich client applications also make for more efficient use of available resources, eliminate the issue of network latency, and enable the user to work offline.

Overall, relative to the rich client, the browser-based model is wonderful for information technology (IT) administrators, but leaves much to be desired for both developers and end users. The Microsoft .NET Framework programming model serves the interests of all three parties. Its smart client application model combines all the power and flexibility of the rich client model with the ease of deployment and stability of the browser-based model.

This paper provides an overview of the .NET Framework smart client application model, explaining how it works from a high-level perspective, and elaborating on how this architecture compares with the browser-based model.

No More DLL Versioning Conflicts

Dynamic-link libraries (DLLs) built using the .NET Framework are not subject to versioning conflicts. In the past, these common problems were the bane of the systems administrator's existence. They occurred during installation when a new application replaced a shared DLL in the system registry with a different version that was incompatible with some of the other local applications referencing it, effectively breaking them.

By default, applications built using the .NET Framework are self-contained and isolated, resolving assemblies (the .NET version of components) from the local application directory rather than from a global or shared location. With this approach, multiple versions of the same assembly can coexist on the same system without conflict. Furthermore, there is no need to "register" any of the assemblies used in an application. This process is referred to as XCOPY deployment. With XCOPY deployment, to install an application on a computer, simply copy the application directory to the appropriate location on the target machine’s local disk, and it's ready to go. To uninstall, simply delete the application directory.

It remains possible to share assemblies, using a central repository known as the global assembly cache. Each assembly registered here is assigned a strong internal name, derived from its file name, version, culture (such as English, German, and Japanese), digital signature, and public key. Thus, each shared assembly is uniquely identifiable. This allows multiple versions of a given assembly to coexist in the global assembly cache and even run concurrently without conflict, a scenario known as side-by-side execution.

By default, applications bind to the strong name of the shared component that they were built against. Of course, if an administrator ever wishes to change this policy, perhaps in the case of a hot fix, he or she may do so by writing a simple publisher policy configuration file or by using the .NET Framework Configuration Tool, which ships with the .NET Framework.

Top of Page

Deploying Smart Client Assemblies from a Web Server

The assembly resolution model summarized above addresses application stability, predictability, and ease of installation—essentially what happens when the application arrives at the client computer. But how do you get the application to the client computer in the first place?

As before, smart client applications can be delivered by CD, DVD, floppy disk, or via application deployment infrastructure such as Microsoft Systems Management Server. The .NET Framework introduces yet another option: No-Touch Deployment, deploying the application from a remote Web server using the Hypertext Transfer Protocol (HTTP).

Essentially, this process mirrors the browser-based application deployment approach. Using methods provided in the .NET Framework class libraries, an application can be written to download the assemblies it needs dynamically from a remote Web server. The first time a particular assembly is referenced, it is downloaded to the assembly download cache on the client computer and loaded for use. Going forward, if the assembly required is already on the client computer and the version on the Web server has not changed, the local copy will be loaded. If the version on the Web server has been updated, that new version will be downloaded and executed. Thus, updates are automatically propagated to the client, but the network is not flooded with redundant downloads.

Note that assemblies are downloaded dynamically, only as they are referenced. This allows applications to load quickly—no 50-MB, half-hour installation process just to get started.

Implementing No-Touch Deployment

Currently, you can implement No-Touch Deployment in three different ways. Each is outlined below:

1. URL Launched Executable:
   Put your executable out on a remote Web server, and let the user navigate to it by entering the URL in Microsoft Internet Explorer or by clicking on a hyperlink to that URL (for example, http://RemoteWebServer/myExe.exe). The executable will be downloaded to the assembly download cache on the client machine and launched from that location. DLLs required by the executable can be referenced as normal in your code. Unless informed otherwise (see #2 below), the common language runtime (CLR) will look for the DLLs in the same directory on the remote Web server as the executable, and the CLR will download them into the assembly download cache from there, as needed.
   
   The downside to this approach is that the user does not find an icon with which to launch the application, but must navigate to the destination URL or click on a link in an HTML page every time. Again, if the version on the Web server has not changed, the .NET Framework will launch the version of the executable stored in the assembly download cache. Technically, the experience is sound. From a usability perspective, however, this process leaves something to be desired.
2. Use the Assembly.LoadFrom method from the System.Reflection class:
   This is helpful in two scenarios. In the first, the initial executable was launched via a URL (see #1 above), but now needs to access DLLs that are located in a different directory on the server or on a different Web server altogether. In the second, more common scenario, the application is architected so that there is a small, lightweight executable installed on the client machine. This executable need not contain much in the way of core logic. Ideally, it just references the DLLs it needs, which reside out on a remote Web server and which supply all of the necessary application logic. Having the executable installed on the client machine in this way means that the user will have an icon with which to launch the application. Again, installing the executable could be as easy as copying it onto your user's local disk—no registration required. The code samples below give guidance on how to use Assembly.LoadFrom:

In C#:

  Assembly downloadedAssembly;
  Type formType;
  Form downloadedForm;
	
  try
  {
   //download and load the assembly
   downloadedAssembly = 
      Assembly.LoadFrom("http://[RemoteWebServer]/CSharpForm2.dll");
   // find the type in the assembly for the object we want to create
   formType = downloadedAssembly.GetType("CSharpForm2.Form2");
   //Create an instance of the desired type and show it
   downloadedForm = (Form) System.Activator.CreateInstance(formType);
   if (downloadedForm != null)
   {
	downloadedForm.Show();
   }
  }
  catch (Exception exc)
  {
    MessageBox.Show(exc.ToString());
  }

 

3. Use the .NET Application Updater component:
   This is a handy piece of sample code written by one of the .NET Framework program managers at Microsoft. It is quite simple to use, and provides native support for offline access and gives the developer more flexibility in terms of when the Web server is polled to check for updates to the assemblies stored there. For more information on this component, visit the .NET Application Updater Component page on GotDotNet.

Code Access Security: Making No-Touch Deployment Safe

For system administrators and users to feel safe about downloading and running applications from a remote Web server, there must be a security system in place that protects client computers from activating a virus or other harmful code. To prevent security breaches from happening, the .NET Framework supports a powerful, fine-grained, evidence-based security system, enabling code to be trusted to varying degrees, depending upon its origin and other characteristics such as its digital signature or the identity of the author. For example, code loaded from an intranet Web server will not be allowed to access the client computer's Registry or file system or gain network access to any other server on the network besides the one from which it originated. Meanwhile, code bearing a particular digital signature or Authenticode signature might be granted significantly more permissions, such as the ability to read from, but not write to the local disk, the ability to revise some environment variables, the ability to interact with three of the seven available databases on the network, and so on. The .NET Framework ships with default security settings that are safe and appropriate for most situations. Systems administrators can use the .NET Framework Configuration Tool or a scriptable command line tool to modify these settings as desired.

At run time, the .NET Framework execution environment, the common language runtime (CLR), performs low-level security checks with a technology known as code access security. This technology ensures that code executes only those operations allowed by the security policies it has been assigned. In doing so, the CLR checks not only the permissions allotted to the assembly attempting a particular operation, but also those of all the other assemblies in the stack that might be calling the active assembly to act on their behalf. Only operations approved in this comprehensive stack walk will be performed.

If software developers are concerned that their applications will not run properly without a certain minimum set of security permissions, they can specify their requirements in advance with attributes included in the assembly's metadata. If these permissions are not granted, the assembly will not be loaded.

This security architecture ensures that unauthorized code cannot access or otherwise abuse the local system in any way, and gives IT administrators more granular control over the applications running on their systems.

Smart Client Versus Browser-Based Application

With these smart client technologies, it's easy to see how the platform-specific application model reflects a practical approach to software development. But how does it compare with the browser-based model? Consider the following.

Work Offline

One obvious but critical advantage that smart client applications have over browser-based applications is the capability to work offline. Practical Internet access is anything but ubiquitous. According to IDC, at the end of 2002, approximately 38.9 percent of U.S. households engaged in some form of home-office activity.¹ At that time, according to The Yankee Group, only 16 percent of those households were expected to have any form of high-speed connectivity to the Internet.² This means that, assuming a remote worker has access to the Internet (not a given for those traveling and seeking to work from hotels, airports, or airplanes), chances are he or she will be forced to endure an irritatingly slow dial-up connection every time an attempt is made to access or manipulate data using a browser-based application. Even if high-speed access is available, what happens when the server goes down? With smart client applications, these problems can be avoided. Once the necessary assemblies are downloaded to the local disk, the user can work productively offline.

Harness the Full Power of Available Resources Efficiently and Safely

Web-based applications are often architected so that all processing is handled by the servers. The advantage of placing the entire burden on the server is that it makes it easier to push an application to multiple different types of clients. The disadvantage is that, for even the simplest request, the client-side user must endure both network latency and the amount of time it takes the server to queue up the given request and process it.

Performing some or all of the work locally with smart client applications means quicker response time and reduced network and server workload, making for more scalable infrastructure. A smart client application can run without any interaction with the network and the server, completely freeing up that infrastructure, or it can go to the server as needed to dynamically download an assembly or to invoke an Extensible Markup Language (XML) Web service. The fact that even some of the work will be done locally—loading and implementing the UI controls, for example—results in a more dynamic user experience and much more efficient use of the infrastructure available, both client and networked.

Web-based applications can be architected to offload some of the processing to the client using scripting or Microsoft ActiveX® controls, but both have limitations when compared with the smart client application model. By default, Web-based script essentially runs in a "sandbox" and is prevented from accessing local resources. Scripted applications cannot read from or write to a client user's local disks, so all data must be stored on a remote server. Again, this causes problems when the user is faced with a slow Internet connection or wishes to work offline. Scripted applications are also unable interact with applications housed on the client computer, such as a Microsoft Excel or the Microsoft Outlook® messaging and collaboration client (as explained in the next section). They can certainly offload some of the work from the server, but they do not have the crucial flexibility of smart client applications when it comes to interacting with the local computer. Furthermore, they are incredibly difficult and expensive to develop well. Dynamic Hypertext Markup Language (DHTML) applications can replicate some of the look and feel of a Microsoft Windows®-based application.

However, while many tools are available for creating basic HTML UI, good tool support for building rich, dynamic DHTML is virtually nonexistent. The UI must be coded by hand. With smart client applications, a developer can simply drag and drop controls onto a form in Microsoft Visual Studio® .NET, and most of the code is generated automatically.

ActiveX controls overcome this barrier, to some degree. They can be developed in integrated development environment (IDE) tools and they enable a Web-based application to access local system resources, but their security architecture is not up to par with that of smart client applications. Users must decide whether or not to run the control. Once the control is activated, there is no way to limit the access it has to the local computer.

Smart client applications built on the .NET Framework have the best of all possible worlds. The Windows Forms libraries enable quick and easy Windows-style UI development that can be implemented either by hand-coding or by dragging and dropping controls onto a form in Visual Studio .NET. Smart client applications can access the local system but only in so much as they are allowed by the .NET Framework evidence-based security policies, as described above.

Again, it is no longer an all-or-nothing security decision but a fine-grained determination that can permit some operations but forbid others. Finally, the burden of this decision is taken off the user and handled transparently by CLR, using either the default security settings or those configured by the system administrator.

Access Local APIs

Smart client applications can leverage powerful Windows-based APIs that are unavailable to non-ActiveX browser-based applications. For example, smart client applications can utilize the graphical power of the GDI+ libraries. Smart client applications can tie into the Microsoft Office APIs, enabling developers to manipulate Microsoft Word, Microsoft Access, Excel, Outlook, and Microsoft PowerPoint® through their own applications. Smart client applications also have the ability to listen for incoming network requests, thus enabling peer-to-peer connectivity. This example, in particular, deserves a section all its own.

Use Peer-to-Peer Technology

In a peer-to-peer scenario, a computer can act as both client and server, making requests of other peer computers and responding to requests placed on it by these peers. According to the Gartner Group, peer-to-peer technologies "will allow users to spontaneously communicate, exchange data, [and] cooperatively run application programs."³ One example of this is a file-sharing system, in which an application running on one computer can search for and retrieve a desired file from a peer computer while making its own files available in reciprocation. Another example is an application running on one computer that can seek out those computers on the network with spare processor power and disk space and harness these unused resources for its own use, enabling a corporation to more fully leverage the infrastructure available to it.

Peer-to-peer technology represents a powerful paradigm with tremendous promise, but it can only be implemented using smart client applications. Web browsers, being user-driven by design, do not have the necessary capacity to listen for and respond to spontaneous requests made by other clients on the network.

Consume Web Services

Just like browser-based applications, with just a few lines of code, .NET Framework smart client applications can consume functionality provided by Web services. Web services provide a model for distributed computing based on standard, platform-neutral protocols such as SOAP, XML, and HTTP. Web services enable applications to interact regardless of what underlying platforms they may be running on and provide a perfect way to integrate new applications with legacy code.

Consume a Web service

1. In Visual Studio .NET, go to the Solution Explorer, right-click on References and select Add Web Reference.
2. Enter the URL where the Web service of choice is located. (In the sample code below, we'll use an imaginary calculator Web service.) Then, select Add Reference.
3. Steps 1 and 2 will create a local proxy of the Web service that you can program against as though it were a DLL residing on your development machine. Note: The code below works whether you are building a smart client application or a Microsoft ASP.NET browser-based application.

In C#:

 try
  {
  //instantiate the XML Web service
  CalcWebService1.Calculator calc = new CalcWebService1.Calculator();
  //get the values from 2 textboxes on your form and enter them into 
  //the Add method of the XML Web service
  int value1 = Convert.ToInt32(textBox1.Text);
  int value2 = Convert.ToInt32(textBox2.Text);
  int result = calc.Add(value1, value2);
  //Convert the result to a string and display it in the label on 
  //your form
  String tempString = Convert.ToString(result);
  label1.Text = tempString;
  }
  catch (Exception exc)
  {
    MessageBox.Show(exc.ToString());
  }

Proven Success

Already, a wide range of software development shops, from corporate IT departments to independent software vendors (ISVs) to professional service firms, have embraced the .NET Framework smart client model as the appropriate architectural solution for their development needs.

At Credit Suisse First Boston (CSFB), a leading global investment banking firm, developers working in the Securities Division are creating smart client applications that will be deployed from Web servers and will allow fixed-income securities traders to enter and view the status of their trades. "Smart client technology enables us to vastly reduce the cost of deploying applications and vastly simplifies the support requirements of those applications," says CSFB Vice President Andrew K. Smith, who runs CSFB's London-based Coretech group. "It also allows us to combine the ease of deployment of HTML pages with the rich client experience we're accustomed to from Visual Basic interfaces." Smith estimates that deploying desktop applications from Web servers in this manner will save the bank millions of dollars in IT expenses.

Intuitive Manufacturing Systems (IMS), an ISV that provides enterprise resource planning software to small and medium-sized manufacturing companies around the world, chose the smart client model over a browser-based architecture for the next release of its best-selling IntuitiveERP software. No-Touch Deployment from a Web server, coupled with the prospects of a richer UI and the leveraging the processing power and memory of the client computer, made IMS' choice an easy one.

Immedient, a business and technology consulting firm with offices throughout the United States, recently ported a billed accounts receivable tracking application to the .NET Framework for the General Services Administration, one of its clients. The firm originally considered using a browser-based architecture but found that Windows Forms coupled with No-Touch Deployment from a Web server offered a richer and more intuitive interface, better performance, and the flexibility to run offline, while providing all the deployment and maintenance benefits of browser-based applications.

 

Conclusion: Where and When to Implement Smart Clients

The smart client architecture is not ideal for every scenario. In situations such as e-commerce, where user platforms are unknown or diverse, the browser-based model continues to represent the most practical approach. However, in the context of a corporate computing environment, where clients are known to be running the Windows operating system, the smart client model is the architecture of choice, combining the power and flexibility of rich client applications with the stability and ease of deployment associated with browser-based applications.

---

¹ "Residential Broadband: Is DSL Conceding the High-Speed Access Race?" (The Yankee Group, May 31, 2002)

² "U.S. Home Office Forecast and Analysis, 1999—2004" by Mary Porter and Ray Boggs (International Data Corporation, June 2000)

³ "Seeking New Investment Opportunities: The Next Paradigm" by R. Batchelder, S. Hayward, and A. Roussel (Gartner Group, September 2001)