WebForms and WebServices: The End of Web programming

Introduction

When it comes time to architect your Web applications, maybe you should just avoid them. The .NET framework provides a superior environment for creating Web applications and it’s not ASP.NET.

The title of this article probably got an immediate response from you and it was probably “Don’t be stupid!” That may just be your reaction to Microsoft’s ambition to rule the world. If the title had been “Java and Web Services: The End of Web Programming” would you have reacted the same way?

However, I’m not being provocative: Web Services and the ability to download client applications should change the way you architect your applications. Specifically, it should mean abandoning your current set of technologies for creating Web-based applications, at the very least for intranet applications.

Think of the way that Web-based applications currently work. The process begins when a user clicks on a hyperlink (or enters a URL into the browser’s address box) to request your page. To respond to this request you’ll have written some server-side code that generates what I’ll call a “browser-enabled program.” That browser-enabled program has its user interface defined using HTML (a very limited tool for creating effective user interfaces). You will have written the code for that browser-enabled program in JavaScript (not a bad language but, still, a scripting language). Furthermore, the code in the browser-enabled program is prevented from accessing any resources on the client computer or any resources back on the server (or on any other server, for that matter).

Once your server-side code has built the browser-enabled program, you send it off to the browser and your server loses all contact with the program. Hopefully, the program runs on whatever browser the user is working with and the display of the UI isn’t too distorted. Also, hopefully, the data from the browser-based program will eventually be sent back to the server. If the data does come back through various programming tricks your server-side code will attempt to make sense of what the user did while interacting with the browser-enabled program. Your server-side code, operating in a batch mode and with no interaction from the user, then processes the data and takes whatever action seems appropriate (typically building another browser-based program to send to the client).

If this wasn’t awkward enough, when you built and tested this application, you used a very different set of tools from those you would use to create a full-featured desktop application.

Let’s be honest: The only way that people could enjoy working in this environment is if they’re paid by the hour.

The new model

Both Java and .NET offer a different way of creating Web-based applications. The user still clicks on a hyperlink but this time the Web server downloads a complete program, written in a real programming language, and with a full-featured user interface. The program has been compiled into a language that will execute on any computer and operating system. The user interacts with this application, which, in turn, accesses any resources on the server that it needs by using Web Services. The program may even be granted access to resources on the user’s computer and to Web Services on other servers. When the user is done, they dismiss the program.

The next time that the user wants the application, they can click on the hyperlink (and, if the system is smart enough, it won’t download the application unless there’s a new version).

The best part: You built this application with the same toolset as you use for any other application.

I am, of course, describing the model for Java and Web Services. But I’m also describing the model for .NET WebForms and Web Services using the no-touch deployment model (this model is enhanced in the next version of .NET, where it’s called ClickOnce).

Given the benefits of this new model offered by .NET, why isn’t everyone rushing to it? There are two reasons:

• Inertia. We’ve invested a lot of time and effort in the old model and aren’t ready to abandon it.

• For this to work, .NET must be installed on the client computer.

It seems to me that the second reason is the real limitation—but it’s not a limitation for intranet applications. Inside a company, there seems to be no reason not to install the .NET redistributable (Dotnetfx.exe) on everyone’s computer and switch over to this model. In the outside world, .NET will take longer to penetrate to every computer even when the Mono project delivers on its version of .NET for the Linux/Unix platforms (and it’s possible that Sun may yet figure out how to make Java the dominant player and usurp the role that Microsoft would like .NET to have). So, for this paper, I’ll discuss this solution in terms of implementing it on an intranet.

Implementing and Securing

If you want to take advantage of this new model in .NET, there’s not a great deal that you need to do: Build a Windows Form application, compile it, put the EXE on your Web Server, and give your user a link that points to your EXE. When the user clicks on the link in Internet Explorer, IE will download the EXE and start it running. If your application depends on any class modules, just make sure that the DLL for those classes are in the same directory on your Web server as the EXE. What could be easier than that?

In fact, your initial reaction should be that it’s far too easy. Downloading a complete application to your hard disk where it could do any harm that it wanted is (literally) an invitation to trouble, even in an intranet.

Fortunately, the computer that the application is downloaded to controls what the downloaded application is allowed to do. Granting permissions to downloaded applications is handled through the Microsoft.NET Framework Configuration menu choice on the Administrative Tools menu. Drilling down through the Runtime Security Policy | Machine | Code Groups takes you to where you can set up permissions for code from various sources (see figure 1). You can use the User node to set up permissions on a user by user basis but I’ve assumed that, if an application is downloaded to a computer, you want the application to treat all users on the computer the same way, which is why I’ve used the Machine node to set permissions.

Fig. 1: The .NET Configuration Management tool

Already listed under Runtime Security Policies are the default groups for various kinds of applications. Applications are assigned to groups based on the evidence associated with the application. The default groups look primarily at the evidence on where the application came form (e.g. LocalIntranet_Zone, My_Computer_Zone). Each group has assigned to it a permission set, which controls what the application is allowed to do (permission sets are listed under the Permission Sets node). The good news is that the default permissions for the LocalIntranet_Zone are probably “good enough” for most intranet application. In the LocalIntranet_Zone, the application is not allowed to access the user’s hard disk but is allowed to access the server that it was downloaded from. For an application gathering data to be used to update a database server at the Web server, these permissions are probably adequate.

If you need more access (for instance, to allow the application to keep a users’ preferences file on the user’s hard disk) you can alter the permissions for an application. You can assign a different permission set to the application’s zone, alter the zone’s permission set, or create a new code group that the application will belong to.

Altering existing permission groups isn’t always a good idea unless you know everywhere that permission group is used. As an example, the permission group called Internet doesn’t control permissions for applications downloaded from the Internet so altering it will do you no good at all. Changing the permission group used by a zone is also not a good idea unless you have a clear idea of all the applications that might fall in that group. You might enable a malicious application that you weren’t aware of.

In general, the best solution is to create a new code group that checks for evidence associated with your application, create a new permission group with the permissions that you want, and then assign the new permission set to your code group. The Configuration manager makes this easy to do (you can duplicate existing permission sets, for instance, to give you a starting point for your new permission set).

You can create a code group that applies only to applications from a particular Web site (one of your company’s intranet sites) and give applications that meet the criteria for the code group additional privileges. The process is simple:

1.                  Select Internet_Zone in the Net Configuration dialog

2.                  Click on Add a Child Code Group in the right hand pane to bring up the Create Code group wizard

3.                  Assign a name and description to the code group. Click the Next button

4.                  Specify the evidence that controls membership in the code group. For an application being downloaded over the Internet, a condition based on the URL is usually the best choice. When you specify a URL, you can specify the complete URL for the application (i.e. applying these permissions to a single application) or use wild cards to give these permissions to all applications from the URL. Click the Next button.

5.                  Set the permissions either by selecting one of the pre-defined permissions sets or creating your own permission group. If you set up your permission group, for each permission that you assign you can specify how much freedom you will allow. For instance, under File IO you can specify which file paths the application is allowed to access and which of Read/Write/Append/File Discovery you are permitting.

If a program attempts to perform an “unpermitted” action, a dialog box pops up  to notify the user and the application is shut down (Figure 2).

Fig. 2: The dialog generated when an application attempts to do something that isn’t permitted.

There are several ways to distribute new code groups and permission sets to your users’ computers (see the article http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms11122002.asp for one method). You can even have your users download a Microsoft Installation (.msi) file through the Web browser that will set up the groups. Allowing MSI files to be downloaded opens a larger security hole than you’re probably willing to expose. To begin with, MSI files are not .NET applications, so they aren’t managed by the permission sets that you’ve set up. Furthermore, in the Custom Actions section of an installation, any action can be performed. Instead, you’ll want to handle distribution of your code groups and permission sets through the same process that you use for installing new applications on your users’ computers.

Handling Delay

One problem remains: even on an intranet, accessing a web server is a slow process. When users are working with a browser, their expectations for response time drop dramatically. However, once you deliver a full-featured application to your users, they’ll expect response times typical of a client/server or desktop application.

Web server response times are going to hurt you in two ways:

• When using a Web Service to access server-side resources

• When downloading additional classes used by your application

The architectural solution to the first problem is to avoid “chatty” designs that require constant interaction. For instance, the application should issue a single request to a Web Service for a dataset that contains all the tables necessary to populate all the listboxes and comboboxes on the form rather than request each table separately. You can also switch from using Web Services to using .NET Remoting, which offers many of the benefits of Web Services with much faster response times.

While it’s tempting to solve the second problem by architecting monolithic applications that download as a single unit, you should avoid the temptation. To begin with, you will impose a longer wait time on the user when the application is first downloaded. In addition, the typical application includes both high-use and low-use features—it seems cruel to make the user wait while you download features that the user won’t access. Finally, should you enhance or fix any part of the application, the user will be forced to download the whole application the next time that they use it. Breaking your application up into modules will have the effect of the user downloading only the components they need or that have changed.

You can also reduce the impact of the wait times on your user by using asynchronous processing and “trickling down” your application on as-needed basis. Asynchronous processing allows you to start a request to a Web Service and then go on to do something else while the request is processing. You can also download parts of your application asynchronously, while still interacting with your user.

Asynchronous processing

With Web Services, asynchronous processing is relatively easy. For each method on the Web service there will be a Begin and an End version of the method. If the method that retrieves the Dataset of tables for listboxes and comboboxes is called GetListData, then there will also be methods called BeginGetListData and EndGetListData.

The Begin method accepts any parameters that the Web Service’s method does but also accepts two additional parameters. Those parameters hold objects that the proxy class needs: an AsyncCallback object and an object of undetermined type. If the GetListData method needs to be passed a single parameter (country code, for instance, to control which countries data is used), then BeginGetListData will take three parameters: the country code + the two parameters that asynchronous processing requires.

The Begin method returns an IAsyncResult object, so you’ll need to declare an object of that type to catch the result of calling the method. Both of the additional parameters that the Begin method requires are optional so you can just pass Nothing to those parameters (or null in C#):

The End version of the method returns the value returned by the underlying method and, if the method hasn’t finished processing, waits until the method has completed. You must pass the End method the IAsyncResult object returned by the corresponding Begin method. This code will retrieve the Dataset produced by the GetListData method:

The other step that you may want to take to avoid web delays is to enable asynchronous downloading of the components used by your application. The following routine downloads an assembly that contains a component that my application will use. The code just passes the Assembly object’s LoadFrom method the URL of the assembly to download:

I would call this routine before my application actually uses the component that is part of this assembly. When the application goes to use the component, it will be loaded from the local hard disk rather than forcing the user to wait for the component to be downloaded from the web server.

By calling this routine asynchronously, you can even download the assembly while the user is interacting with other parts of your application. There are just three steps required to call my routine asynchronously:

1. Create a delegate to be used to call the routine:

2. Declare a variable as being of this type:

3. Associate the variable with the actual routine

Now you can call the download routine asynchronously by using the delegate’s BeginInvoke and EndInvoke methods, just like the Begin* and End* versions of the Web Service’s methods:

Before letting your code use the component, you’ll want to make sure that the download has completed. You can check the IsCompleted property of the ias object and, if necessary, call the EndInvoke method on the delegate to wait for the download to finish:

Conclusion

With some planning on your part, you can deliver to your users —over your intranet—a full featured application with response times equivalent to a desktop or client/server application.