An Up-Close Look at Microsoft's Long-Awaited Web Application Development Tool.
Like a cat with nine lives, Microsoft Corp.'s often-renamed and reincarnated Web application development tool is back again, and this time it's really shipping. Microsoft's Visual InterDev product, formerly code-named Internet Studio, is a tool for Web developers who build complex and intensive Web client/server applications. Visual InterDev centers around a visual development environment that integrates all of the tools necessary to build and deploy complex and intensive Web applications.
The Visual InterDev Web development tool is aimed at Web (Internet and Intranet) database developers. Web authoring tools such as Microsoft FrontPage, Sausage Software HotDog, SoftQuad Inc. HotMetal Pro, and Netscape Communications Corp. Navigator Gold and Composer in the new Communicator suite are intended more for Web content authors than Web developers. These tools may provide some support for adding applets and scripting to Web pages, but they focus on giving Web content authors tools to build and manage sets of Web pages. Many of those Web authors never go near a database.
Visual InterDev supports building server-side applications using a new feature of Microsoft Internet Information Server (IIS) 3.0 called Microsoft Active Server Pages (ASPs, formerly code-named "Denali"): ASCII text files containing text, HTML, and scripts. ASPs are prototypes for server-side processing of database access, state management, server-side scripting, and reusable server components. Visual InterDev also has built-in database development tools that enable access to any database supporting ODBC.
Visual InterDev includes Web site-management tools, such as a visualization tool for ongoing site-management tasks. Visual InterDev also includes a version of the FrontPage WYSIWYG Web authoring HTML editor, as well as tools for developing Web-based images and sound effects.
Web developers can use Visual InterDev to build complex and intensive Web client/server applications accessible by any Web browser on any Web client. The development tool itself runs on Windows 95 and Windows NT Workstation 4.0. A Visual InterDev Web client/server project is stored on a Microsoft Personal Web Server running on Windows 95. It can be stored on a Microsoft Peer Web Services Version 3.0 running on a Windows NT workstation; it can also be stored on a staging or production Microsoft IIS 3.0 running on a Windows NT Server. During file editing, Visual InterDev retrieves files from the Web server and places them into a working directory on the developer workstation. Visual InterDev makes extensive use of ASPs.
Contemporary Web client/server focuses on the Web client side. Microsoft, Netscape, and others seem to be promoting creating fat Web clients by encouraging Web developers to stuff Web browsers with ActiveX components, Java applets, JavaScript, and VBScripts. Doing so helps with distributed systems management realities. Everywhere you look, Web client/server is being described as a "killer" technology on the Internet. Unfortunately, it is also killing Web browsers. Web servers are force-feeding browsers more and more complex information.
There is a better way, however. The server side of a Web client/server application is the appropriate place to use ActiveX, ADC, DCOM, IIOP, Java, JDBC, JScript, VBScript, and other technologies such as Microsoft's Transaction Server (previously known as "Viper). There, scaling computing resources is more economical. In a way, it is déjà vu all over again; we have gone full circle, from central computing to distributed computing and back to central computing. This time around, the dumb terminal of yesteryear is no longer dumb. It is a workstation running a server-independent Web browser and using public-domain TCP/IP network technology. A lot of the legacy blatant proprietary lock-in technology has gone undercover with the coming of Web client/server technology. Some vendors now mask lock-in devices under the cloak of "Open" something or other.
It is possible to do almost everything on an IIS 3.0 Web server using ASPs. Taking this approach means that complex and intensive Web applications are accessible to the most humble of Web clients as long as they have enough steam to run a Web browser. This may be an important consideration with emerging Network Computer (NC) technology driven by anti-Wintel and the Wintel NetPC initiative. It is too soon to tell.
Using Visual InterDev is an excellent way for Web developers to create and maintain complex Web client/server applications using ASPs. Of course, Visual InterDev is also an excellent way to develop complex Web client/server applications requiring Web servers to force-feed already-fat Web clients. The choice is yours.
Web client/server application HTML development and scripting development become the same process when using ASP. Developers embed both HTML and script statements within the same ASP file. IIS 3.0 includes native support for VBScript and JScript, Microsoft's answer to Netscape's JavaScript. IIS 3.0 also supports other scripting languages such as PerlScript, Python, and REXX through Active Scripting plug-ins.
ASP uses the <% and %> delimiters to enclose script commands and the <%= and %> delimiters to enclose output expressions. These delimiters differentiate script commands from text, HTML tags, and Web client-side scripting. The IIS 3.0 Web server checks for an .asp filename extension when a Web browser makes a request. When the Web server detects an ASP file, it searches for the <% and %>, and <%= and %>, delimiters in the file. It processes any code between them and writes any generated output to the output buffer. The Web server copies anything not between the delimiters directly to the output buffer. In other words, you can have VBScript processed by the Web server, and VBScript passed through the Web server without processing, in the same ASP file. When the Web server finishes processing the ASP file, it sends the contents of the output buffer to the Web browser. The default scripting language for ASP is VBScript. ASPs use just-in-time compiling technology to compile Web server-side scripts to byte code automatically on an as-needed basis. Changes made to a Web server-side script cause the compilation process to happen automatically.
Server-side scripts can perform a number of tasks by using objects built into IIS 3.0 ASPs. These tasks include gathering information from the user, retrieving data from a database, and dynamically constructing HTML pages that are returned to the Web browser. Five built-in ASP objects are Application, Request, Response, Server, and Session. The Application object enables information sharing among all users of an ASP Web client/server application.
The Request object retrieves values of parameters that Web browsers pass to the IIS 3.0 Web server during an HTTP request: It stores them in object collections. The Request object collections are values of fields stored in the client certificate, values of cookies, values of form elements, values of variables in the HTTP query string, and values of predetermined environment variables. The following ASP snippet outputs the value of Monster cookie to the Web browser:
<BR>The value of the cookie named Monster is:
<%= Request.Cookie("Monster") %>
<BR>
The Response object enables you to manipulate the HTML and HTTP sent back to the Web browser. The Response object collection lets you specify cookie values. The Response object properties are output buffer information, HTTP content type, Web browser page-caching time, and ASP return status. The Response methods let you set HTML headers, append to the Web server log, and erase buffered HTML output. They also let you stop ASP file processing, flush the output buffer, send and redirect messages to the Web browser, and write a variable to the output buffer. The following ASP snippet uses the Request.Form method to retrieve the value of the yourname element from the form collection and then writes it to the output buffer:
<BR>Hello, your name is: <% Response.Write Request.Form("yourname") %>
The Server object provides access to methods and properties on the Web server. Most of the methods and properties are utility functions. The Server object property is the amount of time the script can run before it times out. The Server object methods create an instance of a server component, apply HTML encoding to a string, map a virtual path, and apply URL encoding rules. The following ASP snippet sets the maximum amount of time the script can run before it times out to 60 seconds:
<% Server.ScriptTimeout = 60 %>
The Session object stores state information needed for a user session. Variables stored in the Session object are not discarded when the user jumps between pages in the Web client/server application. Session variables persist for the entire user session. The IIS 3.0 Web server automatically creates a Session object when a Web browser requests the first .asp page. The Web server destroys the Session object when the session expires; it also destroys the Session object when the Web browser abandons the session. Session state information is only maintained for Web browsers that support cookies.
The Session object properties are the session identification for this user and the time-out period for the session. The Session objects single method destroys a Session object and releases its resources. The Session events are Session_OnStart and Session_OnEnd. The following ASP snippet causes the session state to be released when the server finishes processing the current page:
<% Session.Abandon %>
ASP also supports IIS 3.0 Web server components (or automation servers). These components are Ad Rotator, which automatically rotates advertisement displays; Browser Capabilities, which determine Web browser capabilities; Content Linking, which creates tables of contents for a Web client/server application; and File Access.
The underlying network and UI technologies for Web client/server applications are fundamentally different from legacy client/server applications. Web client/server applications use HTTP network connections to Web servers. These network connections are established, broken, and re-established as the Web browser requests HTML pages and other objects over the network. Legacy client/server applications rely on persistent network connections between the client and server. Web client/server applications use Web browsers as clients and a GUI based on a workstation.
Developers use Visual InterDev at design time to create and edit ASPs. They embed scripts within them using JScript, VBScript, PerlScript, Python, or REXX. The following ASP snippet contains HTML and VBScript; it passes through the IIS 3.0 Web server to the output buffer without processing.
<HTML>
<HEAD>
<TITLE>VBScript Embedded</TITLE>
</HEAD>
<BODY>
<SCRIPT LANGUAGE="VBScript">
<SCRIPT>
<!- Process on Web browser
..
. . . VBScript Code . . .
->
</SCRIPT>
</BODY>
</HTML>
The IIS 3.0 Web server processes script statements between the <% and %>, and <%= and >%, delimiters. ASPs can generate client-side HTML code that the Web server sends to the Web browser for processing. The following ASP snippet contains HTML statements that pass through the Web server to the output buffer without processing. It also contains VBScript statements that the Web server processes and then sends on to the Web browser.
<HTML>
<HEAD>
<TITLE>Hello World</TITLE>
</HEAD>
<BODY>
<% for i = 3 to 7 %>
<font size=<%=i%>>Hello World</font><BR>
<% next %>
</BODY>
</HTML>
The Web server sends the following HTML snippet to the Web browser from the output buffer:
<HTML>
<HEAD>
<TITLE>Hello World</TITLE>
</HEAD>
<BODY>
<font size=3>Hello World</font><BR>
<font size=4>Hello World</font><BR>
<font size=5>Hello World</font><BR>
<font size=6>Hello World</font><BR>
<font size=7>Hello World</font><BR>
</BODY>
</HTML>
Figure 1 shows a Web browser rendering of the HTML script snippet.
The developer workstation maintains an ODBC connection to the Web client/server application database server over a Local Area Network (LAN) at design time. The developer workstation functions as a client of the database server in a traditional client/server way.
ActiveX Data Objects is a new Microsoft data access programming model. If you are familiar with Data Access Objects (DAO) or Remote Data Objects (RDO), you will recognize the ADO interfaces and be readily able to work with them. Active Data Objects are specifically designed for Web client/server data access. They provide an object-based approach to accessing data over the Web. You can establish database connections to any ODBC data source through ASP scripting. You can select database-defined datatypes -- such as binary large objects (BLOBs) and .gif and .jpg images from databases -- and then write them to the ASP output buffer using ASP scripting. Other ADO properties are setting locking levels, cursor options, query and login time-outs, transaction support, resultset scrolling, and error handling.
The Data View feature gives you a visual interface to all of the databases being used within a Web site. It depicts each database connection being used in the site and provides a live connection to each database so that you can work directly with these databases within the IDE.
Visual InterDev provides built-in components, Wizards, and design-time ActiveX Controls to generate much of the ASP scripting. They generate the necessary scripting and ADO calls to establish database connections, perform queries, and display results, within a Web client/server application. You can use design-time ActiveX Controls to create data-driven Web client/server applications with little additional programming. You can also choose not to use design-time ActiveX Controls and instead develop and optimize ASP scripting and ADO calls yourself.
The Database Designer is a special feature of Visual InterDev. Based on the Visual InterDev extensible architecture, the Database Designer lets you create database diagrams and key relationships between tables. It has the graphical ease-of-use of Microsoft Access to set up and administer Microsoft SQL Server databases without leaving the Visual InterDev IDE. Support for other database systems will most likely be added in the future.
Visual InterDev has a Web visualization tool called Link View that presents a graphical view of Web client/server applications. I should note here that Microsoft recently announced its acquisition of NetCarta and will incorporate NetCarta into BackOffice and IIS as another way to navigate or display the structure of a Web site.
Developer organizations can use Microsoft Visual SourceSafe 5.0 with Visual InterDev for Web client/server project source control. Visual SourceSafe is not required to be installed on the developer workstation. All Visual SourceSafe features execute on the Web server.
Microsoft can improve Visual InterDev by integrating client- and server-side debugging into the product. The company could also improve state management. One way would be to generate a unique token that identifies the Web client/server application and the Web client, store this token in a cookie, and use it as a Registry key. Web developers could use the Registry to store arbitrary Web client information between sessions without using the Web client/server database.
Microsoft has set the standard for an interactive, integrated Web client/server application development environment. Other vendors in the Web tool marketplace now have a product to meet or beat.
