In my last column (see "Caught in the Crossfire," DBMS, October 1997), I stated that the real trick in developing intranet applications lies in balancing functionality between client- and server-side execution. As a result, your choice of server has as much or more impact on developing intranet applications as your choice of client does. I've chosen Microsoft's Internet Information Server (IIS), and my team (at The EC Company) is getting geared up to build registration, billing inquiry, and royalty management applications on our corporate intranet. If we are successful, we will deploy these applications to external customers as well as to internal customer service personnel.
My current plan is to employ a "mostly Microsoft" solution for building these applications, using the Microsoft Visual InterDev site-development tool to coordinate Active Database Object connections, HTML pages, and active server pages. The principal component of our solution that's not from Microsoft will be an Oracle database. We decided to use Oracle as the backbone for our electronic commerce services and that we would be best-off using the same database product for our support applications as our production applications. In this column, I'll present an overview of Microsoft's Active Platform as it stands today, share the thought process that led me to select it as our development platform, and describe the process of building an intranet application with Visual InterDev.
Microsoft introduced the Active Platform at its developer conference a little more than a year ago. Because it was the third model that Microsoft had introduced to support data-oriented Web applications, many of us took a wait-and-see stance. During the past year, the platform appears to have asserted itself as the "real" direction that Microsoft will take for Web application development; I don't expect any significant directional shifts as we move forward. With more people recognizing this, acceptance and deployment of Active Platform applications has accelerated. It no longer surprises me to log on to a Web site and see that the response file has an .asp extension. Most recently, I noticed that the United Airlines reservation site uses ASP. While I was unable to find out how many hits the United site gets, I did learn from my contact there that it is using components heavily and that it uses ASP to access a fairly heterogeneous data and applications environment.
"Active Platform" is a loose-fitting term. Microsoft is more likely to talk about Active Client, Active Server, and ActiveX technologies. Taken together, these compose the Active Platform. I covered the Active Client, as viewed from the vantage point of Internet Explorer 4.0, in my previous column. The Active Client browser component renders HTML 3.2 with its dynamic HTML extensions, Microsoft's Java Virtual Machine (VM), language-independent scripting using VBScript or Microsoft's JavaScript-compatible scripting (JScript), and access to local and networked objects via ActiveX. The Active Client is part of Internet Explorer 3.0 and 4.0, but it can be integrated with any client application.
ActiveX is a set of technologies that allows COM objects, such as ActiveX controls, to communicate in a local or networked environment. ActiveX components can interact with one another regardless of whether the object is local or remote. ActiveX Scripting and Automation deliver a common model for how scripts and objects can communicate, independent of scripting language or object language (VBScript, JScript, C++, Visual Basic, Java, and so on).
Active Server refers to Windows NT Server functioning as a Web application deployment platform. In a typical deployment, it would include IIS 3.0 with its server-side page generation ("Active Server Pages") facility, the DCOM and Active Data Objects component technologies working in conjunction with a relational database (Microsoft prefers SQL Server), and Microsoft Transaction Server functioning as a component coordinator. NetShow provides streaming media services for both audio and video, and Index Server enables searching and indexing of both Web pages and documents for those sites that require these capabilities.
ActiveX Data Objects (ADO) is a COM object whose object model provides functionality to access data maintained by any datasource that has an OLE DB provider. Active Server pages instantiate ADO for all their data access functions. As a programming model, ADO is not dependent on a specific database API, however, the only engine currently supporting the ADO model is OLE DB. Microsoft posts references and samples on its Web site at www.microsoft.com/data/ado/.
The ADO object model consists of seven objects:
In ADO, as in Microsoft's other object-based data access models (DAO and RDO), the recordset object is the main interface to data. ADO offers the other six objects primarily to support creating and using recordsets. The ADO programming interface communicates with OLE DB to fulfill its service requests.
ADO deemphasizes the object hierarchy by letting developers create recordsets without having to instantiate workspace and database objects, which are not included in this object model, or connection objects, which are. This makes it a more flexible object model in which a programmer can reuse the same object in different contexts. I don't consider ADO (which is certainly less verbose) to be as well-suited for implementing fully functional database applications as DAO and RDO. For instance, its lack of table and database objects compels you to fall back on SQL commands as the means of maintaining database structures.
The ADO objects afford a great deal of control over how the recordset behaves, with properties for setting locking levels, cursor options, query and login timeouts, transaction support, result set scrolling, and error handling. In particular, the connection object's mode property allows the designer to select from among seven concurrency models, which control how a connection should respond to a request to open another instance of the connection. The mode property determines whether others can open another instance of the connection and what access level (read, write, or read/write) they can obtain; the selected mode applies to all recordsets created on the connection. The IsolationLevel property specifies what level of transaction isolation should be applied to a connection. ADO permits the designer to base a recordset on a read-only, forward-only cursor, a dynamic cursor that makes all changes to the database visible, a keyset cursor that behaves like a dynamic cursor but does not add new rows when they are added to the underlying table, and a static cursor that is essentially a copy of a set of records. It also supports specifying whether locks applied during editing should be pessimistic, optimistic, or batch optimistic. Taken together, these options enable design decisions based on the number of users, the number of transactions, and the relative frequency of writes, reads, and transactions, among other factors.
The Active Server Pages framework itself provides an object model with five built-in objects: Application, Request, Response, Server, and Session. When ASPs execute, they create their built-in objects automatically at the appropriate times. The objects have a small number of property collections, events, and methods that script code can reference. Their compact nature makes it very easy to learn the model. Most significantly, the application encapsulates each server application and each user session as an object. This facilitates management of applications and sessions across a series of users and requests. The server object provides a context for executing Active Server Components (for example, external OLE-compliant DLLs).
The ASP engine permits Web applications to provide a global initialization file, named global.asa. Script in this file can specify event scripts and declare objects that have session or application scope. An application starts the first time a user opens one of the Web pages in the application and ends when the server shuts down. The application has two events: an Application_OnStart event and an Application_OnEnd event. If an application will make repetitive use of a specific automation server, it would be prudent to instantiate it in the Application_OnStart event. Creating variables scoped to the application makes it possible to maintain global processing or tracking information, such as the number of visitors or the number of queries performed.
The session object provides a mechanism for maintaining information associated with a specific user session. ASP creates this object when a new user arrives on the home page, and persists until the user explicitly leaves the application, the session times out, or the application executes the "abandon" method on the session object. The developer or administrator can set the time-out interval as a property of the session object. To maintain running totals representing a specific user's activity during the course of a session, you can dynamically create variables scoped to the session in the initialization file. Application scripts can update these variables, which can represent indicators of the user's activities or running balances of the transactions that the user has performed.
Of course, we are going to consider using ActiveX Data Objects in the context of data aware Active Server Pages. Active Server Pages are really quite simple. They consist of HTML and script code that executes on the server and returns HTML. With Active Server Page extensions installed, Microsoft IIS recognizes files with .asp extensions as executable files. When a browser requests such a file, IIS calls the ASP.DLL application through the Internet Information Server API (ISAPI). The DLL does the work of processing the ASP file and returning the resulting HTML page to the Web server.
To read and write data in ADO recordsets manipulated through Active Server Pages requires creating an ADO connection object and creating a recordset object on the connection. These two steps require a handful of lines of script code in an ASP file. There are actually three ways to create a recordset. The Server.CreateObject ("ADODB.Recordset") method accomplishes this task, as does the Execute method of either a Connection object or a Command object. These latter methods provide the ability to specify parameters, which is especially useful when using a stored procedure to generate the recordset. Once the recordset has been created, the script can reference field values in the current record as RecordSet_Name ("fieldname").
What's really interesting about Active Server Pages is that they can consume and incorporate just about any kind of COM object that resolves either to HTML or to a value that can be returned to a script. An HTML layout is an example of such an object. Microsoft has distributed an HTML layout control that is essentially a wrapper for their Forms package that consists of a design panel, lightweight UI controls, and a tool palette from which to select them. It's the same form designer that they include with VBA. After saving an HTML layout in a file with an .alx extension, you can open the file with an editor and see a series of object definitions. You can reference an .alx file as an object in an ASP, and the server-side page processor will generate the specified UI controls and embed them in the resultant page. After working on it for a short period of time (and I only had to learn how to do this once!), I was able to assign the values of an ADO recordset to the "Value" property of textbox and other controls.
The ASP supports development of multitier applications by allowing developers to create ActiveX Component Servers (formerly OLE Automation Servers) that perform business services and data access. This is not quite as mystical as it sounds. I created a simple ActiveX DLL in Visual Basic that had no user interface but performed a validation task and returned a simple true or false value. To use the automation server took two lines of code to instantiate the COM object and call the ChkValid method.
Set oValidate = CREATEOBJECT("VBActive.class1")
bIsValid = oValidate.ChkValid(cChkVal)
Based on the return value, I am able to control which page displays next. Of course, you can create a server application that exposes numerous methods and properties and executes them all very simply in this manner. Microsoft supplies an example application in which all data access is buffered through method calls, a technique that probably provides the greatest scalability.
Quite honestly, the notion of developing an entire application by hand writing ASP scripts was a daunting proposition. Fortunately, Visual InterDev (VI) goes a long way toward alleviating the pain of that process. Although version 1.0 has some rough edges, the leverage it provides is quite powerful. Because I'm focusing on intranet applications that are supposed to perform a range of data management functions, I've spent the most time with VI's tools for building data-aware forms. There are several. Three are packaged as design time controls, ActiveX controls that the designer uses when building the application to specify the content and behavior of ADO recordsets. Design time controls are an interesting concept; they are tabbed dialogs packaged as ActiveX controls that you execute from inside an HTML or ASP editor. When you fill out the dialog and dismiss it, the control inserts script code into the editor representing the behavior you specified; if you need to make changes later, you can reinvoke the control from within the generated code.
The Data Command design-time ActiveX Control creates a recordset object using the project data connection and the CommandText that you specify in the Data Command Properties window. The Data Range Header and Data Range Footer design-time ActiveX Controls work together to bracket a section of HTML code that will be repeated for each record in a recordset. The Data Range Header writes server script that creates an ADO recordset object using a query or stored procedure that you specify and begins a loop to move through all the records in the recordset. You can either display a list of records in an HTML table or a form that displays a single record on a page. The Data Range Footer writes the server script that finishes the loop that processes the recordset. The Data Command control is geared to applications that need to provide lookup functionality or modify data. The Data Range Header/Footer controls are ideal for publishing a lot of data on a page.
The Data Form wizard combines the functionality of the design time controls with settings that determine what types of data aware pages to create. It allows the designer to indicate whether the presented data is read-only, and if not, whether to permit inserting, modifying, or deleting records. The designer can also request that the generated pages offer the ability for the user to apply an additional filter on top of any conditions specified in the initial query. Depending on the designer's responses, the Data Form wizard creates one or more Active Server Pages containing forms that let users search, update, delete, or insert data to an existing database on a server.
These pages have a common structure. The first section presents the actions that the user can perform. The second section consists of code generated by a Data Range Header control called implicitly by the data wizard. The third section contains the code to display a single record. In my application, it looks like this:
<% If strFormMode = "Edit" Then Response.Write "<P>" Response.Write "<TABLE WIDTH=100% CELLSPACING=0 CELLPADDING=2 BORDER=0>" ShowField "bank_name", "bank_name", False, Null ShowField "branch", "branch", False, Null ShowField "contact_na", "contact_na", False, Null ShowField "city", "city", False, Null ShowField "state", "state", False, Null ShowField "phone", "phone", False, Null Response.Write "</TABLE>" Response.Write "</FORM></P>" stQueryString = "?FormMode=Edit" fHideNavBar = False fHideRule = True Else fHideNavBar = True fHideRule = True End If %>
This script code calls the generated showfield function that displays the value of the field and its caption. Its behavior is based on its last two parameters that determine whether the field is read-only, and whether the code should build a list box from a lookup table to display a list of allowable values.
If the designer specifies that the dataset should be updateable, the wizard generates an "action" ASP file, and identifies this ASP file as the response file for all button actions on the data display pages. The script on this page processes the user action and then either reruns the script that displays the page that called it or displays a confirmation of the action or information about an error that caused it not to complete its processing. All this generated code provides a great starting point that a developer can customize or use as the basis for creating additional custom pages.
VI also supplies a nice interactive query designer that supports the ActiveX design time controls. Designers can also call it from the VI IDE. With the query designer open, they can open live views of data sources, and drag tables into the design pane. As they select fields from the tables, the query designer will show the dynamically constructed SQL statement. This is a live two-way tool, in which changes to the SQL code are immediately reflected in the designer, and you can execute the query at any time to test it and review the results. Since the SQL pane is live, it provides a single place where the designer can create stored procedures, execute data definition commands, or perform ad hoc queries. When the designer is satisfied with the query, the tool generates HTML and server scripting that can be embedded in an ASP file.
What turned me on about using Active Server as the core of my deployment was its ability to leverage our team's existing skills and scale up while staying on an NT platform. Many of us have developed applications in Microsoft Visual FoxPro (VFP) or Visual Basic (VB). Microsoft has borrowed several capabilities that appeared earlier in VFP, most notably the flexible cursor controls that manifest themselves in ADO, the concept of using a familiar scripting language to generate code, and design time controls that generate code like the VFP builders. Obviously, VB Script is not much of a leap for VB developers. The seamless integration of ActiveX Server components into ASP scripts, and the ability to author these components in VB or VFP allows us to reuse our existing application development skills even further. Using ActiveX server components and distributing them to balance load across NT servers should provide us enough horsepower to extend our intranet out to tens of thousands of customers.
We won't have any control over what browser or what computing platform those customers are using. That's where the concept of using a server-side page generation architecture becomes extremely attractive. While the ability of this technology to limit bandwidth requirements is not critical to throughput on our 100-user LAN, it becomes critical when we start to move our applications to the Internet. There we want to avoid distributing any controls or applets and would prefer to concentrate on fast HTML delivery. While the CGI tools I've reviewed in the past perform in a similar fashion, they lack the interactivity that the ASP model provides and the flexibility in choosing component development tools.
Of course, I'm looking forward to seeing the continuing maturation of the Active Server technology and the VI tool. The lack of an editor that presents a visual representation of the page that you are defining needs to be addressed, as does the lack of a code-level debugger. The inability of the design-time wizards to support JScript is, in my view, a serious deficiency. There should be better tools for maintaining server-side forms after you initially create them. For instance, if you generate script with an HTML layout control, you have to copy it to an ASP file and you can only maintain it by modifying the generated code. Microsoft is aware of these shortcomings (I'm sure I wasn't the first to identify them) and will soon be previewing a new version of the product in which it promises to address many of them. All in all, version 1.0's shortcomings do little to dampen my enthusiasm for the platform. I'm looking forward to delivering applications to my colleagues that are very responsive to our business requirements.
What did you think of this article? Send a letter to the editor.