Page #37 (Chapter 4 - Introduction to WebClasses)

	Chapter 4 - Introduction to WebClasses
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	Comparing the Advantages and Disadvantages of VB/WebClasses vs. ASP

	Now that you've built both an ASP and a WebClass project, it's useful to compare the relative strengths and weaknesses of each for building Web applications.

	Because VB uses the full Visual Basic language, whereas ASP uses VBScript, VB is much more powerful.

	First, VBScript uses only the Variant data type. If you assume that the speed of an ASP application is similar to the speed of the variant routine (and you can), then you just saw an example of how using VB and WebClasses can speed up your code. Variants, due to their size and the need to check variable subtypes, usually run slightly slower and in some cases much more slowly than "primitive" data types.

	Second, you can compile VB code—the ASP engine always interprets code. Because the VB interpreter is highly efficient already, compiling an inefficient application won't usually provide a large increase in speed. Using the previous example, however, compiled with all optimizations selected, the byteConcat function executes five times as fast—in .03 seconds rather than .15 seconds. In contrast, the other functions execute in almost exactly the same amount of time whether you compile the application or run it in interpreted mode. I used this example because a great deal of Web application programming consists of merging data with HTML for presentation. Therefore, in certain situations, a compiled application can provide both better response and greater scalability.

	Finally, compiled code has one more advantage—nobody can see your application code. If you have security issues, are selling applications commercially, or just don't want anyone to copy your code, you will want to avoid ASP, in which the code is available to anyone who has access to the server.

	ASP does have some advantages. For instance, it needs only one standard installation because the IIS setup program installs and registers the ASP DLLs with the Web server. After that, to install a new application you need only create a virtual directory and copy the ASP files. In contrast, you have to install the VB runtime files. You must individually install and register VB WebClasses—but after you've accomplished that, you can run them on remote or multiple servers. ASP code runs only on the Web server. Therefore, the trade-off here is ease of delivery vs. scalability.

	In addition, ASP code (without the Windows Scripting Host) is relatively safe for Internet Service Providers (ISPs) to run on their servers. Even if you write an endless loop, an ASP page will eventually time out (in 90 seconds by default). ASP programs can't write binary files. In contrast, VB WebClasses present security and reliability risks. Because they're regular Windows DLLs, they're free to do whatever they like (including crash the server), within the permissions assigned to the account under which they run. Many ISPs and business clients won't install them on their servers.

	Finally, ASP can run on other platforms besides Windows (currently some Unix platforms), whereas VB runs only on Windows.

	Having used both, I recommend that you choose VB when the application re-quires a lot of server-side processing, when you have the ability to install ActiveX code on the server, or when security needs dictate the use of compiled code.

	Choose ASP when the application doesn't need the power of a compiled language, when delivering to a location where you are not allowed to install ActiveX code, or when delivering to non-Windows-based servers.

	Taking the long view, ASP was never intended to be both a formatting engine and a code engine; it was meant to be a "glue" environment that lets you connect browsers and Web servers to back-end business and database components. Because VB has been honed and optimized over the years, it's an ideal system for building those components. With the advent of ActiveDirectory services and COM+, you'll be able to build your business components in VB, connect them to multiple back-end databases, and deploy them on multiple servers using MTS (or COM+) to control transactions and cache objects. These capabilities lead to an "ideal" Web application, where rather than trying to increase your server speed, you can simply offload most of the processing to other servers as your application's user base grows.

	This ideal Web application looks something like Figure 4.5. There's a set of clients, one or more Web servers and one or more Name servers, a Business Services layer, and a Data Services layer. The clients make requests to the Web servers. The Web servers call the Name servers to find business objects on the network and pass requests on to these business objects. The business objects retrieve and store data in multiple back-end databases and return formatted HTML combined with data to the Web servers, which return the pages to the client.

	Figure 4.5: An ideal Web application

	Remember that this is an ideal application. Certainly, you do not need to develop every Web application using this model, but if you need scalability, you should be working toward a model similar to this one.