How Do Web-Based Applications Differ?

How Do Web-Based Applications Differ ?

From a COM+ perspective, Web applications can differ significantly from their desktop counterparts. For example, youll find that desktop applications are substantially easier to troubleshoot in many cases because all resources required to diagnose the error are local to the application environment (even if the connection exists across a LAN). Web applications also present compatibility problems not found in desktop applications. For example, despite all the time people have spent working on browser compatibility issues, compatibility problems still exist. Where standards do exist, theyre often new and untested or poorly worded (leaving some decisions to the imagination of the developer). Creating a stable environment takes more time and is a more significant issue with Web applications.

This section of the chapter discusses some differences between desktop and Web-based COM+ development. We dont intend this section to be a complete list of every problem youll encounterthink of it more as a listing of the kinds of problems that can occur. In addition, youll learn a little about the functionality Microsoft continues to add to COM+ to make it a friendlier environment in which to work.

COM+ 1.5 and SOAP

One of the first new features youll find in COM+ 1.5 is the ability to create a Simple Object Access Protocol (SOAP) setup for your COM+ application. For purposes of discussion, this section relies on the MyMath.dll file discussed in several other chapters (including Chapter 2 and Chapter 5). The version of the MyMath project used for this example appears in the Chapter 11\MyMath folder of the source code.

Note 

The example in this section will work only on platforms that support COM+ 1.5, such as Microsoft Windows XP and the Windows .NET 2003 server. This example wont work on earlier versions of Windows, including Windows 2000. You must use the MyMath.dll file for this project and not an earlier version. Create the application using the technique found in Chapter 2 rather than the RegSvcs technique. The technique in Chapter 2 creates a COM+ 1.5 applicationthe RegSvcs technique creates a COM+ 1.0 application, even on platforms that support COM+ 1.5.

Youll begin the project as usual by creating a COM+ application named MyMathApp and installing the MyMath component. Figure 11-1 shows the SOAP configuration setting on the Activation tab of the MyMathApp Properties dialog box. Notice that the figure shows the Uses SOAP option checked and MyMathMethod entered in the SOAP VRoot field.

Figure 11-1: Adding support for SOAP to your COM+ application is relatively easy.

When you click Apply, COM+ creates several files for you that become accessible from Internet Information Server (IIS) as an application. Figure 11-2 shows the results of this process. As you can see, the application includes several files and a bin folder.

Figure 11-2: Setting the SOAP support options automatically creates some application files for your IIS setup.

Accessing this application displays a simple Web page containing the name of the SOAP application. When you click the MyMath.MathFunctions.soap?WSDL link, youll see the Web Services Description Language (WSDL) output generated for this application, as shown in Figure 11-3. The WSDL describes the MyMath.MathFunctions class and the services it provides.

Figure 11-3: The WSDL output of the Web page describes the class and the functionality it provides.

You can obtain the same output by using the SoapSuds utility. This utility accepts various input and generates output using a number of techniques. For this example, its most convenient to obtain the required information directly from the Web site and place it in an XML file. Heres a typical command line for this utility. (Youll also find the SoapSudsData.bat file in the Chapter 11\MyMath\bin\Debug folder of the source code.)

 soapsuds-url:http://localhost/MyMathMethod/MyMath.MathFunctions.soap? WSDL-os:MyMathService.xml 

Once the Web application is in place, using it is easy. All you need to do is start a new project and create a Web reference by right-clicking the References folder in Solution Explorer and choosing Add Web Reference from the context menu. When you browse to the location that holds the MyMathMethod application, youll see a list of discovery services for that server. Select the link for the MyMathMethod application and youll see a service description like the one shown in Figure 11-4. Click Add Reference and your application will have access to this COM+ application through SOAP and the IIS server.

Figure 11-4: The Add Web Reference dialog box can help you locate and use services.

Note that you can always choose to view more information about the features offered by the COM+ application from within the Add Web Reference dialog box. Simply use the same URL you used to view the COM+ application on the Web site using the browser. For example, in the case of this sample application, I used the URL http://localhost/MyMathMethod/MyMath.MathFunctions.soap?WSDL . This URL produced the output shown in Figure 11-5.

Figure 11-5: You can also view the features provided by an application by using the same URL that the browser provides on the Web site.

A strange thing happens to the MathFunctions class as part of its transformation from COM+ application to SOAP application. Figure 11-6 shows that the class now sports two ways of working with the functions. The developer can choose synchronous or asynchronous communication. The SOAP Quick Test application youll find in the Chapter 11\QuickTest folder of the source code uses both communication methods . You can get the books companion content from the Web at http://www.microsoft.com/mspress/books/6426.asp .

Figure 11-6: The SOAP form of the application has additional functionality not provided by the COM+ version.

This added functionality is a free bonus that you dont have to code. It makes your component just that much easier to use. Listing 11-1 shows the code used with the SOAP Quick Test application.

Listing 11-1: The SOAP Quick Test application

 privatevoidbtnSynchronous_Click(objectsender,System.EventArgse) { //Gettheinput. intInput1=Int32.Parse(txtInput1.Text); intInput2=Int32.Parse(txtInput2.Text); //CreatetheMathFunctionsServiceobject. MathFunctionsServiceMFS=newMathFunctionsService(); //Performasynchronousadd. intResult=MFS.DoAdd(Input1,Input2); //Sendtheoutputtothedisplay. txtOutput.Text=Result.ToString(); } privatevoidbtnAsynchronous_Click(objectsender,System.EventArgse) { //Gettheinput. intInput1=Int32.Parse(txtInput1.Text); intInput2=Int32.Parse(txtInput2.Text); //CreatetheMathFunctionsServiceobject. MathFunctionsServiceMFS=newMathFunctionsService(); //Performanasynchronousadd. MFS.BeginDoAdd(Input1, Input2, newSystem.AsyncCallback(MyCallback), null); } publicvoidMyCallback(IAsyncResultar) { //CreatetheMathFunctionsServiceobject. MathFunctionsServiceMFS=newMathFunctionsService(); //Obtaintheresultoftheoperation. intResult=MFS.EndDoAdd(ar); //Sendtheoutputtothedisplay. txtOutput.Text=Result.ToString(); } 

 

As you can see from the listing, making a synchronous call isnt much different than making a direct call to the COM+ application. (See Listing 8-2 in Chapter 8 for an example of a Visual C++ application that calls the DoAdd() method in the MyMathApp COM+ application.) You instantiate the MathFunctionsService object and then call the DoAdd() method to add the two input numbers . Obviously, the .NET Framework has made it easy for you to make SOAP calls without worrying about the SOAP coding that used to take place.

The asynchronous call is still simple, but its not quite as straightforward as the synchronous call. The code still begins by instantiating the MathFunctionsService object. In this case, the code calls the BeginDoAdd() method with the name of the callback method as the third parameter. The MyCallback() method follows the format of the System.AsyncCallback delegate. The fourth parameter is an optional asynchronous state object you can pass to the callback method we dont need it in this situation.

The MyCallback() method receives an IAsyncResult variable, ar . This variable actually contains a significant amount of information about the call. However, all we need for this example is the result of the addition. Notice that the code begins by instantiating the MathFunctionsService object again. It calls the EndDoAdd() method with the IAsyncResult variable and converts it to text for display.

COM+ 1.5 and Application Dumps

A new entry on the application Properties dialog box for COM+ 1.5 users is the Dump tab. Figure 11-7 shows what this tab looks like. As you can see, it helps you save a dump of your application to disk. You can load this image of the application into WinDbg for later analysis. (WinDbg, part of the Debugging Tools for Windows, is available on the Web at http://www.microsoft.com/ ddk/debugging/ .) This option is less useful to the managed application developer than it is to the unmanaged application developer, but its still useful in either case.

Figure 11-7: Use the Dump tab to save a copy of your application to disk.

Heres the interesting part about this feature. You can set it up to dump the application to disk whenever an error occurs. It wont dump for something minor that you designed your application to handle, but it will create an image for a major faultnormally from an unhandled exception. In sum, this new debugging feature can help create a better environment for your applications. However, its probably the option of last choice because most developers know that WinDbg isnt an easy debugger to use and definitely wont help much with the managed aspects of your code.

Youll want to make a few changes to the setup in most cases. The first change that I make is to modify the Image Dump Directory value. The default setting places the dump in the %systemroot%\system32\com\dmp folder. If Im at work on an application, I normally place the dump file in a subdirectory of the project folder. Production applications normally have a special folder on the server, so the dump folder also appears in this location.

A second recommended change to the default setup is modifying the Maximum Number Of Dump Images setting. Generally, youll want a high number for comparison purposes during the development stageI normally set up my machine for 10 images. Once you have the application debugged , its unlikely youll need this feature very often or at all. Given that the average server is a little short on space, clogging the hard drive with extra dumps doesnt make sense. I normally set the number of images to 1, at this point, to save space.

Component Interactions

Many problems developers face are the result of interactions between two application elements. Component interactions can take on a new meaning with Web-based applications. For example, in the application youll study later in this chapter, theres an ASP script between the client and the server. The ASP script accepts data requests from the client, creates an instance of the required component, formats the data obtained by the component, and outputs it to the client. In short, the client and the server arent even directly connected. (The same can be said of the SOAP application found in the COM+ 1.5 and SOAP section of the chapterjust look at the files shown in Figure 11-2.)

The loss of a direct connection between the client and server can create situations in which the client and server cant communicate well. For example, in preparing the SOAP example for this chapter, I found that an IIS configuration problem caused the MyMath component to fail, although the exact same component works fine when used with a direct COM+ connection. In many cases, the problem is a matter of losing the connection. Because of the way HTML handles components that must be kept alive, the client could lose the context it establishes with the server before the client completes whatever task it needs to accomplish. The point is that you should treat every ASP script query as a new call, even if the Web server keeps the original connection alive .

Scripting also presents other problems. Creating an instance of an object using a script is seldom the same as creating an instance of the same object with a desktop application because of the scripting environment. Consequently, you might find that components wont work at all with your script or that they behave differently than you expect them to. You can get around this problem by thoroughly testing a component during development. Make sure you include scripting tests as part of your test suite. Its also important to make sure the component behaves the same no matter what type of desktop application or script is calling it.

Developers design many components with callbacks in mind. The client makes an initial query, and then the component uses a callback to obtain additional information from the client. Since Web-based applications are unreliable when it comes to communication, its important to design the component to rely on the clients initial query without any callbacks. In short, always assume the worst-case connectivity scenario and youll have fewer problems with applications that work fine on the development system but fail when they finally make it to the production system.

Scripting Error Handling

Youll almost certainly rely on scripts, in some way, when working with Web- based applications. In fact, youll probably need a combination of client-side and server-side scripts to make the application fully functional. Client-side scripts normally dont present much of a problem when it comes to error handling. Either the script works or it doesnt. While the error code the user gets might seem somewhat cryptic, its usually easy to locate the problem and fix it because client-side scripts are small and usually limited in scope.

Server-side scripts present other kinds of problems. Most scripting languages dont provide error handling. In addition, passing the error information along to the client might prove difficult without a lot of additional coding. Of course, .NET developers have a significant advantage in this area because ASP.NET provides approximately the same error-handling features that the desktop environment does. In addition, you can use advanced languages such as C# to create your applicationa real plus when working with complex applications.

Finally, unlike standard desktop applications or components, many scripting languages provide little access to the event log, denying the developer of even this potential method of recording errors. (Again, using ASP.NET provides the means for creating robust applications that do have access to features such as the event log.) In sum, the developer has to be exceptionally careful when creating the server-side script. Providing range and other nonerror producing checks will help reduce problems. If a range or other easily detectable problem is encountered , the script can always provide client feedback in the form of a special Web page.

Fortunately, IIS (at least the versions on Windows 2000, Windows XP, and the Windows 2003 Server) provides rudimentary script-debugging capabilities. Under Windows 2000 you can install this feature separately using the Windows Components Wizard, which is accessed by using the Add/Remove Programs applet in Control Panel. Simply select the Script Debugger option shown in Figure 11-8. For other versions of Windows, you can download the Microsoft Windows Script Debugger from MSDN at http://msdn.microsoft.com/downloads/ default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/731/msdncompositedoc.xml .

Figure 11-8: Some versions of Windows provide a separate Script Debugger option you can install.

Once you have debugging installed, youll be able to activate it by clicking Configuration on the Virtual Directory tab of the application Properties dialog box. Select the Debugging tab, and choose the debugging options you want to use. Figure 11-9 shows the required entries. Once you add this feature to your development platform, youll always be able to debug scripts.

Figure 11-9: IIS provides a script debugger that helps in locating potential problems in your Web-based application scripts.

Human-Language Support

One of the biggest problems youll run into when working with a Web-based application is the issue of human-language support. The Internet isnt a closed environment. If you plan to make a Web-based application open to the public through the Internet, youll need to provide support for more than one language.

In many cases, the problem isnt one of translating the content of your Web site. There are many well- understood methods for translating text from one language to another. The main problem is one of application usage. For example, the captions on your application will need to change to support the other languages. You could place the required information in a database that the application could download as needed. The most recently used languages could get stored in a local database or even in the registry.

However, you need to consider even broader issues. For example, the layout of your application must be flexible enough to accommodate the way people normally work, or users will complain the application is difficult to use. This means allowing users to configure the display. While this isnt a problem with most desktop applications, it is a little more difficult with a Web-based application because you dont have control over the position of the various components. In most cases, the best you can do is store the user preferences in a cookie. You can then use the contents of the cookie to configure the display as the application downloads data from the server (or better yet, configure the data at the server).

Accessibility Concerns

Most companies are beginning to realize the importance of making their desktop and Web applications accessible. The creation of new laws requiring accessibility supportsuch as the Section 508 requirements passed by the US government ( http://www.section508.gov/ )is one motivation. Sales to those with special needs is another. Enhancing employee productivity is yet another reason companies are making their applications accessible.

When you work with desktop applications, you have good control over the accessibility environment. In fact, the .NET Framework makes it almost too easy to add support for common accessibility features. The user controls these features through the Accessibility Options applet located in the Control Panel. In general, because most of these functions are nearly automatic, COM+ components you create for desktop use are unlikely to change to meet accessibility requirements.

Web applications present new challenges to the COM+ component developer, even if you rely on managed components. For one thing, you no longer have control over the user environment. In addition, the manner in which a particular browser interprets your page is going to be inconsistent with the interpretation by a browser from a different vendor. In many cases, you can avoid adding complicated code to your COM+ application by using smart development techniques for the user interface of your application. For example, the simple act of using Cascading Style Sheets (CSS) can make a significant difference in the complexity of creating an accessible Web application.

Unfortunately, youll still run into situations where you need to modify the output of the COM+ application to provide additional information to meet accessible application requirements. For example, most accessible application standards require both visual and aural methods of detecting application output. You might find that you need to add extra code to provide the data for both methods.

ASP and Component Communication

One of the ultimate problems with scripting is that you lose the direct connection between the client and the server. The COM+ application might generate an error, but unless the developer who designs the script formats the Web page to pass that error along, the user might never see it. Because a Web-based application normally has a direct connection (you wouldnt create a disconnected application in many cases), its important to pass any component errors to the client.

Unfortunately, simply passing along the error isnt enough in most cases. The problem is that the user wont know where the problem occurred unless you provide additional information. In most cases, the user will assume an error has occurred locally, unless you make it clear the problem occurred within the component.

Of course, complex applications might have several layers of component calls, and it might be tempting to add code so that the user sees the precise location of the problem. Rather than build overly complex components that do little for the user, its better to simply report the error as a component error, and then tell the user to contact the network administrator about the problem. An event log entry will allow the network administrator to determine the precise cause of the problem and take steps to fix it.