The Active Server term was coined in 1996 to categorize the technologies being released with BackOffice that enable tighter integration and exposure to custom development. It is no surprise that the integration model revolved around the Common Object Model (COM) and the ability to drive the services of the BackOffice components using development tools such as Visual Basic, Visual C++, and Visual J++. Each BackOffice component, including Exchange Server, has COM objects that enable a developer to harness the vertical power of the component and produce a horizontal business solution. Figure 34.1 provides a visual depiction of the BackOffice components and where they fit into the Active Server platform.
FIG. 34.1 BackOffice and the Active Server Platform.
As you can see in Figure 34.1, Window NT Server is the foundation for the Active Server platform and is required to run any of the BackOffice applications. Each vertical pillar of the Active Server platform--SQL Server, SNA Server, Systems Management Server, and Exchange Server--provide unique services to the Active Server platform. SQL Server provides for data storage using a relational database. SNA Server provides access to legacy data that is resident on mini or mainframe computers. Systems Management Server is used to manage an enterprise's desktop population. Also, Exchange Server provides enterprise-wide messaging.
Each of the pillars is capped with a layer that enables a developer to create applications that automate common tasks within the vertical application or extract information from the vertical application. This layer is the public COM layer, which provides a set of clearly defined methods and properties that enable the developer to manipulate the vertical application.
The COM layer's methods and properties are controlled using a development tool such as Visual C++, Visual J++, or Visual Basic. Visual Basic is the most commonly used development tool for developing active server applications. A derivative of Visual Basic is VBScript. VBScript is the most commonly used scripting language for Active Server Page development.
Active Server Pages can be developed using any ASCII text editor, HTML editor, or word processor. Most developers, however, would prefer to develop using an interactive developing environment, such as Front Page '97 or Visual InterDev. These two development tools provide the most robust environment for Active Server Page development. The key to making Active Server Pages run is simple: Just enclose the VBScript that is to run at the server within the HTML tags of "<%" and "%>" and save the file with an extension of ".ASP". Well, maybe it is not that easy, and a further explanation of the coding syntax is provided later in this chapter, but the .ASP file extension is important.
NOTE: An alternative to using the <% and %> HTML special tags is to use the <SCRIPT LANGUAGE="VBScript" RunAt=Server> and </SCRIPT> HTML tags to encapsulate scripting code that is to be run on the web server.
The .ASP file extension is important because all files with this identifier are preprocessed by the Internet Information Server via an Internet Server Application Programming Interface (ISAPI) extension. The .ASP file extension is associated with the ISAPI extension, ASP.DLL. ASP.DLL interprets and processes the VBScript code within the Active Sever Page file. The results of the Active Server Page preprocess is HTML code that will be interpreted by the client's web browser.
The browser receives the results of a request made to an Active Server Page that uses the Active Server platform to provide informative and timely dynamic content to the user. An example of how Exchange can be used to provide active content is provided later in this chapter.
Before active content can be developed and published, you must ensure that you have a properly laid foundation. Windows NT Server and Internet Information (IIS) server are the backbone for hosting Active Server Pages, but you need to make sure that you have the correct versions running before you begin to develop.
Windows NT Server 4.0 is the base component needed to host active server content. IIS 3.0 is the Internet web server that makes it possible to host Active Server Pages. Active Server Pages have an advantage over CGI or other technologies because of the simplified process of providing dynamic web content using the technologies of COM and a scripting language such as VBScript.
The Internet Information Server accompanies the Windows NT Server CD or can be downloaded from the Microsoft web site at backoffice.microsoft.com if you have enough patience or bandwidth. Active Server Pages require Internet Information Server 3.0 and Windows NT Server 4.0 with a minimum of Service Pack 2. Instructions for applying the service packs are provided on the CD or in the download files.
NOTE: At the time this chapter was written, Windows NT 4.0 Service Pack 4 had just been released. All examples in this chapter were developed under Windows NT Service Pack 3.
Following the installation of Windows NT Server 4.0, Internet Information Server 3.0, and the appropriate server packs, you can verify that Active Server Pages have been installed by reviewing two Registry entries. The entries are found under HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/W3SVC/Parameters/Script Map. The entries should have a value name of .ASA and .ASP associated with data value c:\[Windows NT directory]\system32\inetsrv\ASP\ASP.dll. Check to make sure ASP.dll resides in the directory specified in the Registry data value.
TIP: When installing Active Server Pages from the service pack, you are given the option to install the Adventure Works sample Active Server Page application, Active Server Page examples, and documentation. I would highly recommend expending the necessary hard drive space to accommodate these excellent resources.
Once you have verified that Active Server Pages process components have been installed on your server, run a quick test by launching the Adventure Works demo application at http://[your web server]/AdvWorks/ or one of the sample pages found at http://[your web server]/ASPSamp. This assumes you heeded the recommendation to install the samples with your installations of IIS 3.0. If not, proceed with this chapter and you'll create your own test Active Server Page.
Once all the service packs have been installed and you've tested to ensure Active Server Pages processing has been installed, you're ready to prepare Internet Information Server for a new Active Server Pages application.
Each Active Server Pages application must reside in its own directory at the web server. A directory and its subdirectories specify the global boundaries of the Active Server Pages application. To draw a correlation between a compiled application and an Active Server Pages application, the compiled application is bound within the address space created by the compiled executable, .EXE. The Active Server Pages application's "address space" is relative to requests made of Active Server Pages within a web site directory.
In order to set up an Active Server Pages application address space, you must configure an Internet Information Server directory. To configure new application directories where all the files necessary for your Active Server application will reside, follow these steps:
NOTE: If the pages are stored on a network, the web server must be able to access the files across the LAN to fulfill the user's request.
FIG. 34.2 The Microsoft Internet Service Manager.
FIG. 34.3 The WWW Service Property's Directories tab.
FIG. 34.4 WWW Service Properties focusing on the Directories Properties dialog box.
You are now ready to begin the development of an Active Server Pages application. The following sections in this chapter further discuss Active Server Pages development and guide you through the development of a simple Active Server Pages application using Exchange Server's public COM interface.
Remember the days when you had to code CGI applications, Perl scripts, or even ISAPI extensions to get anything dynamic out of your web site? It wasn't that long ago, maybe all of two years, but it seems that way now that we have Active Server Pages.
The next few sections outline how Active Server Pages enable you to create dynamic content as easily as creating applications with Visual Basic. So throw away the "C" compiler and jump onboard the ASP train.
Visual Basic (VB) has been the darling of the information technology industry since 1993. With several major revisions and improvements, it has become the language of choice for the development of corporate client-server applications. VB has captivated millions of developers as being the first "object-style" language for the masses. VB gave birth to a whole industry that built reusable components using the Visual Basic Extension (VBX) and OLE Control Extension (OCX) programming models.
With the ground swell of support for Visual Basic in the development community, Microsoft developed a version of VB called Visual Basic for Applications (VBA), which has become the common scripting language in all the Microsoft Office desktop applications. VBA is a subset of the functionality available in VB, replacing WordBasic and Excel's macro language to enable users to learn one scripting language to automate tasks and construct applications based on Microsoft's office productivity tools.
Since Microsoft already had a loyal following with the VB language, it was natural for it to continue to use the VB pyridine when it came to scripting languages for web applications. VBScript, like VBA, is a subset of the functionality available in VB. VBScript can be used at the client browser, assuming that the browser is Microsoft Internet Explorer 3.x or later, or within Active Server Pages in the context of Internet Information System version 3.x or later.
With the ability to use VBScript at both the web browser and web server, you obtain the ability to manipulate publicly exposed COM interfaces in the development of web-based applications. On the client side, these COM objects are known as ActiveX controls. On the server side, these COM objects are known as Active Server objects. The examples that follow concentrate on the development of Active Server Pages that utilize VBScript to manipulate the Active Messaging library of objects provided with Exchange Server to create HTML pages that are returned to the web browser. Because results of an Active Server Page request is HTML code, it does not matter which web browser or operating system the client is using, as long as it properly interprets standard HTML 3.x web pages.
Many companies today struggle with cross platform client-server application development issues. Active Server Pages provides an alternative in the development of these applications. Multi-tiered application development is now underway in many corporations using VBScript as the glue that holds the server-based vertical data services to business rule components and the presentation on the web browser. The web browser becomes the host for "thin client" applications that utilize the Internet/Intranet to provide location independence and harness the power of the "big iron" multiprocessors (multi-megabyte, mass-storage servers that are proliferating themselves within corporations today).
Microsoft has begun to develop more and more Active Server Pages applications as tools for managing and using the BackOffice applications. The first of these Active Server Pages applications was the Internet Service administrator. The web-based version of the Internet Service administrator tool works in much the same way as its compiled counterpart. This gave web masters the ability to manage their web sites remotely via a web browser.
This trend continued with Web-based tools for the management of Windows NT Servers and in Exchange 5.0 Service Pack 1. Then Microsoft introduced one of the first Active Server Page applications for the end user, Outlook Web Access. Outlook Web Access is similar to its Office 97 counterpart, but is completely web based as an Active Server Pages application. Does the Microsoft Outlook Web Access client meet all of your personal information management needs? Your answer is most likely yes, Microsoft has worked hard to provide a client that is feature rich and easy to use at the same time. If the answer was no, you can make modifications easily to Outlook Web Access to tailor it to your company, and at the same time introduce the client to as many platforms as possible. Microsoft has taken a very large step in providing tools and technologies that leverage the Active Server platform and provide access cross-platform via the Internet. This chapter previously discussed the preparation necessary to begin an Active Server Pages application by outlining the proper installation of Windows NT Server and Internet Information Server and adding an Active Server Pages application directory to the web server. For development, however, Internet Information Server doesn't have to be used. Peer Web Server 3.0 for Windows NT Workstation 4.0 and Personal Web Server for Windows 95 can also be used as a development testing ground.
To take our first step in the development of Active Server Pages applications, you need to start with the basics. The first application will be the same application that every other programming textbook uses, the "Hello World" example. The example below assumes that you've created an Active Server Pages directory as outlined previously on the web server called \SampleApp. The following steps outline the syntax needed for your first Active Server Pages applet:
<HTML> <HEAD> <TITLE>Hello World!</TITLE> </HEAD> <BODY> <!-- This is where we'll insert our VBScript --> </BODY> </HTML>
<% Response.Write("Hello World!")%>
NOTE: Active Server Pages applications have several unique intrinsic objects that are used to create instances of Active Server objects, respond to requests, and access application variables. The Application, Server, Session, Request, and Response objects are documented in the Active Server Pages Roadmap documentation that accompanies IIS 3.0.
FIG. 34.5 Results of Hello World ASP applet.
<HTML> <HEAD> <TITLE>Hello World!</TITLE> </HEAD> <BODY> Hello World! </BODY> </HTML>
Now that you have created your first Active Server Pages application, you are ready for a more complex and interesting example. In the next section, you will create an Active Server Page that utilizes the Active Messaging technology for Exchange Server.
Now that you have a basic understanding of what Active Server Pages are, you can explore one step further with Active Messaging, which enables you to take advantage of the Messaging and Collaborative capabilities of Exchange Server. Active Messaging enables you to write Active Server Applications that can read and send mail, access public folders, and access the messaging directory through a web browser. The Active Messaging object libraries and included files are provided by Microsoft to jump start your development efforts by providing a foundation for messaging and groupware application development that is available to multiple client operating system platforms. All the processing that occurs happens at the server. This is why the client web browser becomes agnostic to what platform it is on.
The concept of Active Messaging is not a new messaging model; however, it provides scripting capabilities built upon the existing messaging model of MAPI. To take full advantage of Active Messaging, during the installation of Exchange Server select the option for installing the Outlook Web Access Components. By installing these components, you are immediately capable of connecting to your Exchange server by requesting an Active Server Page through your Web browser.
Key areas that must be discussed if you wish to create full-featured web applications include Messaging Libraries. There are two libraries you can utilize to build Active Server Pages applications:
The Active Messaging Library enables you to send and receive mail.
The Active Messaging Rendering Library is used to render the Active Messaging objects and HTML information.
These libraries can be called from Visual Basic, VBScript, JavaScript, Java, and any application that supports Visual Basic for Applications (VBA). To utilize the libraries, you should have a good familiarity with Visual Basic and an understanding of MAPI.
Like any application development project that involves objects, when you develop applications for Exchange, you need to know its properties and methods. For example, if you are accessing the Recipient object, there are various properties that are addressable, such as Address, Class, ID, Name, and Session, which enable you to either enter or read information on specific details about the object in question. There are corresponding methods that are available for each object, such as Delete, IsNameAs, and Resolve. These methods are the actual means of how to accomplish the task on the property.
When approaching Active Messaging, you also must understand that because MAPI is still the primary interface, a MAPI session must be established for access. The Microsoft Exchange Client default timeout is sixty minutes for authenticated users. The pages included with Exchange provide an example of Active Server Pages scripts on which you can base your development for custom Login screens and mailboxes. The easiest way to understand how to utilize the features of Active Messaging is to walk through an example. The following exercise shows you how Active Messaging can utilize your Web browser to query and display information from your Exchange Server's global address list. As is true with many other development environments, you must rely on libraries to add extra functionality. These libraries include functions that can be called by your program as needed. These and other libraries are automatically installed in the C:\ExchSrvr\WebData directory as part of the Exchange Server installation.
Our Active Server Pages code example is intended to explain the major points to be aware of when developing an Active Server Pages application that interacts with Exchange Server. For a more in depth survey of Active Server Pages applications using Active Messaging, review the sample applications found on Microsoft's web site at www.microsoft.com/technet/appfarm. This web site has a number of Active Server Pages example applications that will provide a wealth of information on the many uses of Exchange Server on the web.
NOTE: The initial invocation of an Active Messaging application executes Global.ASA. This file is supplied with the Outlook Web Access installation, and invokes the base Active Server objects to access the services within Exchange Server. Make sure to copy this file into your Active Server Page application directory when developing an application that interacts with Exchange Server.
Begin your Active Server Page by referencing the standard Exchange Server, including files provided with the Outlook Web Access installation:
<!--#include file='constant.inc' --> <!--#include file='session.inc' --> <!--#include file='getrend.inc' -->
Within Global.ASA, an instance of the Message Rendering object is created and stored within an Application variable. Application variables are shared amongst users accessing the Active Server Pages application. This reduces the overhead required to create and delete objects each time an Active Server Page is requested. In the code that follows, the local variable objRenderApp is set with a reference to the object stored in the Application variable named bstrRenderApp:
<% set objRenderApp = Application( bstrRenderApp ) %>
After a reference to the Message Rendering object is established, properties can be set and queried and methods can be executed. In the code that follows, if the property ConfigParameter("Publish GAL") and the Session variable of bstrAuthenticated are set to "False," then an error is reported:
<% If objRenderApp.ConfigParameter("Publish GAL") = False And ¬Session(bstrAuthenticated) = False Then ReportErrorClose errPageDisabled Response.End End If %>
The following code once again accesses the Message Rendering object's ConfigParameter to determine the publishing limit for the Global Address List (GAL).
This Active Server Page is executed as a result of an HTML form being completed and submitted. Data from the form is retrieved from the requesting form using the Active Server Pages intrinsic Request object. This object contains the collection of the elements within the requesting form. These elements will be used later to create a filter for listing addresses from the GAL. The final line of code in this section establishes a new Hierarchy object that will be used in the next section of code:
<% nPubLimit = objRenderApp.ConfigParameter("Publish GAL Limit") If CStr(nPubLimit) = "" Then nPubLimit = 9999 End If If nPubLimit > 0 Then strDisplayName = Request.Form("DN") strFirstName = Request.Form("FN") strLastName = Request.Form("LN") strTitle = Request.Form("TL") strAlias = Request.Form("AN") strCompany = Request.Form("CP") strDepartment = Request.Form("DP") strOffice = Request.Form("OF") strCity = Request.Form("CY") Set Hierarchy = objOMSession.AddressLists EndIf %>
The Hierarchy object created above is tested to determine if it exists. If it does not exist, an error is reported. If it is valid, processing continues by validating the entries in the Hierarchy collection. Additional error checking is provided to ensure that the address list is valid. Finally, in this section you will create an Address Entry Filter object, which is populated in the next section of code (see Listing 34.1).
<% If Hierarchy Is Nothing Then ReportError1 errAddrBookInvalid End If For i = 1 to Hierarchy.Count Set objAddressList = Hierarchy.Item(i) If objAddressList.Fields(ActMsgPR_DISPLAY_TYPE) = ActMsgDT_GLOBAL then Err.Clear Exit For End If Next If objAddressList Is Nothing Then ReportError1 errAddrBookInvalid End If Set objAddrEntries = objAddressList.AddressEntries If objAddrEntries Is Nothing or Err.Number <> 0 Then ReportError1 errAddrBookInvalid End If Set objAEFilter = objAddrEntries.Filter If objAEFilter Is Nothing or Err.Number <> 0 Then ReportError1 errAddrBookInvalid End If
%>
In the following section of code (see Listing 34.2), filter object is populated with the variables received from the requesting query form. The information from the querying form is used to reduce the scope of the addresses returned and rendered for the web browser.
<% objAEFilter.Or = False If strDisplayName <> "" Then objAEFilter.Fields.Add ActMsgPR_DISPLAY_NAME, strDisplayName End If If strFirstName <> "" Then objAEFilter.Fields.Add ActMsgPR_GIVEN_NAME, strFirstName End If If strLastName <> "" Then objAEFilter.Fields.Add ActMsgPR_SURNAME, strLastName End If If strTitle <> "" Then objAEFilter.Fields.Add ActMsgPR_TITLE, strTitle End If If strAlias <> "" Then objAEFilter.Fields.Add ActMsgPR_ACCOUNT, strAlias End If If strCompany <> "" Then objAEFilter.Fields.Add ActMsgPR_COMPANY_NAME, strCompany End If If strDepartment <> "" Then objAEFilter.Fields.Add ActMsgPR_DEPARTMENT_NAME, strDepartment End If If strOffice <> "" Then objAEFilter.Fields.Add ActMsgPR_OFFICE_LOCATION, strOffice End If If strCity <> "" Then objAEFilter.Fields.Add ActMsgPR_LOCALITY, strCity End If
%>
The final section of code (see Listing 34.3) produces the actual HTML page based on the query submitted by the user. The GetAddressContainerRender function is found in the GETREND.INC include file, which you registered at the beginning of the application. The GetAddressContainerRender creates an object that produces the HTML page that is returned to the user's web browser.
<% Set objRender = GetAddressContainerRenderer objRender.RowsPerPage = objAddrEntries.Count objRender.DataSource = objAddrEntries objRender.Render 1, 1, 0, Response
%>
Our example above demonstrated some of the aspects of using the Active Messaging objects and libraries provided by Microsoft within an Active Server Pages code. The Microsoft Outlook Web Access application is a wonderful example of a feature-rich Active Server Pages application, but even it may not meet the messaging needs of your organization. If your organization has unique messaging requirements, the tools are available to create very robust web-enabled applications using Active Messaging.
Up to this point, the book has strictly dealt with web-enabling Exchange Server using Active Server Pages. Active Server Pages provide for cross platform compatibility in your web messaging applications. But when feature-rich functionality is more important than cross-platform compatibility and you have the luxury of dictating a web browser, there are alternatives. Microsoft has developed a technology called Remote Data Services (RDS), which enables a client web page to invoke methods and proprieties of Active Server objects that reside at the web server.
Remote Data Services consists of two parts: client-side ActiveX controls and a server-side ISAPI extension. These two components provide the communication plumbing and data marshalling between the client's web page and business rule objects on the web server.
The primary functionality of Remote Data Services is to access relational data that is accessible via a web server. A secondary function of Remote Data Service is the capability to invoke custom business objects that perform business rule processing on the server and return responses back to the client's web page. This is where we can hook into Exchange Server to produce very robust web applications.
TIP: For additional information concerning Remote Data Services, please refer to www.microsoft.com/data/rds. At Microsoft's web site you can download the client and server files, review system requirements, and investigate the technology's documentation.
Utilizing Remote Data Services, a web page may make any number of method calls to a business rule object that resides on a web server. The web server does not even have to be the web server where the web pages are hosted. Thus, three-tiered and multi-tiered web applications become a reality. Figure 34.6 visually depicts a three-tiered architecture using the Remote Data Services to interact with Exchange Server.
FIG. 34.6 A web-based, three-tiered application.
Using Figure 34.6, the following is a description of the data flow between the client browser, middle-tiered business object, and the information stored within Exchange Server.
The subject of Remote Data Services or Universal Data Access is a book unto its own. This section was intended to whet the appetite of a developer to investigate the multitude of possibilities available to a web client using Remote Data Services.
To develop messaging applications within the web environment, you must acquire some important skills. As mentioned earlier, a familiarity with HTML, Visual Basic, VBScript, Java, and JavaScript are required. The ability to write code in any of these languages and a working understanding of Exchange Server, messaging, and MAPI are also very helpful.
The tools that can be utilized to develop the applications vary. You can develop the entire application with a text editor to create the scripts and HTML code. To make life easier on yourself, a product such as Visual Studio, which includes Visual InterDev, Visual Basic, and Visual J++ enables you to create Active Server Pages, HTML files, and ActiveX objects is invaluable.
You'll also find that there are a number of resources available on the Internet, several of which have been mentioned in this chapter. As always, Microsoft provides invaluable information via their web sites (www.microsoft.com, backoffice.microsoft.com, www.microsoft.com/msdn, www.microsoft.com/workshop) on updates, code examples, add-ons, and betas. It also contains many technical articles and white papers on the various development skills mentioned previously, as well as news and discussion groups specifically for Active Server Pages.
NOTE: One of the most comprehensive web sites available besides www.microsoft.com for information relating to Active Server Pages can be found at www.genusa.com/asp. This site has a very complete FAQ, tutorial, and software library, and is an excellent resource for Active Server Page development.