| Downloads |
|---|
| 19714.zip |
Exchange 2000 Server provides an excellent platform for developing rich Web-based applications. A premier example of such an application is Outlook Web Access. OWA lets you use a Web browser to connect to Exchange Server mailboxes and public folders so that you can process mail, contacts, and calendar items. In this article, I look at the major architectural components of Exchange 2000 that enable OWA, how you can customize the user's OWA experience, and how you can reuse OWA components in your applications. The box "Related Articles" provides sources for background information about OWA.
OWA 2000's Architecture
Exchange 2000's architecture differs significantly from Exchange Server 5.5's architecture; therefore, it's not surprising that the two versions support browser clients differently, too. The only commonality between the versions is the name Outlook Web Access.
In Exchange Server 5.5 and Exchange Server 5.0, OWA is a Microsoft IIS application built with many lines of Active Server Pages (ASP) code that uses Collaboration Data Objects (CDO) and Messaging API (MAPI) to talk to the Exchange Store. Browser clients connect to the IIS application, and OWA translates the HTTP calls from the browser into MAPI calls and sends them to the Store. OWA then translates the results from the Store back into HTTP calls and transmits them back to the browser client for HTML rendering.
Although this architecture works, it has limited scalability, and the end-user experience isn't exactly rich in terms of functionality and ease of use. One benefit, however, is that the source code ships with OWA. If you want to change the user's experience, you can customize the ASP code. Some customers, particularly ISPs, want to brand the client with advertising and other information, and they can do so only by customizing the code. Customizing the ASP code is neither easy nor safe because any new releases of the ASP code from Microsoft simply overwrite any changes you've made.
The Exchange Server 5.5 architecture limits the OWA 5.5 architecture because MAPI is really the only way to get into the Store. Exchange 2000 fundamentally changes this limitation with native support of Internet protocols, such as HTTP and WWW Distributed Authoring and Versioning. WebDAV is an extension to HTTP 1.1 and includes support for manipulating the properties of items as well as the ability to manage collections of items. When you use WebDAV to access the Store, you use XML to represent information and Extensible Style Language (XSL) to manipulate information, all of which contributes to the success of the OWA 2000 client. In addition, browser technology has improved significantly since OWA first shipped, and the combination of the most up-to-date browser (e.g., Microsoft Internet Explorer—IE—5.5) talking to an Exchange 2000 server offers the client a rich, robust, and well-performing experience.
The support of all Internet protocols in Exchange 2000 occurs through merging IIS (specifically the inetinfo.exe process) and the Web Storage System (WSS—specifically the store.exe process). These processes communicate over high-speed memory queues known as the ExIPC (formerly known as Epoxy) layer. In addition, the Exchange Installable File System (IFS) sends data streams into and out of the Store. Typically, IIS and the Store exchange properties about items over ExIPC, and the bulk of the data moves through the IFS. Figure 1 shows how an Internet Server API (ISAPI) extension implemented in davex.dll supports an HTTP request.
I explain later how a client invokes OWA, but ultimately the browser dispatches an HTTP request with various host headers to the ISAPI extension. The extension inspects the User-Agent host header to determine the client's capabilities. OWA supports two different client families: reach clients and rich clients. The term reach implies that to reach a large audience, you must build your application with the lowest common denominator in mind. In OWA 2000, a reach client is any client that can support HTML 3.2, such as IE 4.01 Service Pack 1 (SP1) and Netscape Navigator 4.08 and later. For reach clients, the server generates mainly HTML content and broadcasts this content to the client for display.
Rich clients support applications that can rely on and harness particular client capabilities. In OWA 2000, only IE 5.x clients have the required capabilities. In this case, OWA uses primarily the WebDAV protocol, XML (for wire transmission), XSL style sheets, Dynamic HTML (DHTML) behaviors, and Cascading Style Sheets (CSS) to provide the client-side experience. Rich clients offer an experience similar to that of Outlook—an important consideration today when users can use the Internet to access their mailboxes from any location and not have help readily available.
For both rich and reach clients, compiled C code running in davex.dll handles generation of HTML and XML content. Lines of ASP code no longer support the browser client; therefore, you must use another method to customize the user experience. If you have currently made changes to the ASP code that shipped with OWA 5.5, you must reimplement these changes before you remove your OWA 5.5 systems. However, you can use OWA 5.5 to access an Exchange 2000 mailbox, so this reimplementation need not stall your Exchange 2000 deployment. Before I discuss the different methods available for customizing OWA, I need to explain the component of the Exchange 2000 architecture that supports access through a browser.
URL Addressability
Because Microsoft designed the WSS to store any type of data, many protocols and clients can access it. The WSS is a URL-addressable store, which means that a user-friendly URL can access every item over the HTTP protocol. Every item in the WSS—folders, mail messages, calendar items, Microsoft Office documents, files, attachments to items—has a URL.
An item's URL has three components:
- The name of the server (or the Fully Qualified Domain Name—FQDN) that hosts the item
- An IIS virtual directory that maps either the mailboxes, default public folders, or general-purpose (application) public folders on that server
- The folder hierarchy to the item
For example, the URL to a document in my mailbox is http://laphroaig/exchange/laahs/articles/owa.doc. The simplest way to find the URL to an item is to use OWA, open the folder containing the item, and hover over the item in the listed content. The item's URL will appear in the status bar of your browser. To invoke the OWA client, you simply connect to the URL http://server/exchange. (In my case, the URL is http://laphroaig/exchange.)
The beauty of combining URL addressability with HTTP access is that you can open any supported browser, type in a URL to an item in the WSS, then experience the default OWA processing for that type of item. For example, if your URL points to a folder, you'll see all the contents of that folder. If your URL points to a message item, the item will display in a message form. If your URL points to an Office document, the Office application will open inside the browser to display the item. For customizability, you need to appreciate the power of this default OWA processing. When you access a folder by its URL, you not only see the items in the folder, you also get all the functionality associated with that folder (e.g., rich and sortable views, new item and deletion buttons)—all without writing any code.
To process an item in a particular way, you can append special commands to that item's URL, then pass in applicable parameters. The commands that you can use depend on the item. For example, you can append the Delete command to a URL that points to an item to delete the item instead of opening it. Passing parameters becomes significantly more powerful when your URL points to a folder because you can force the items within the folder to display in a particular view or be sorted by a particular column. For example, you can force a folder holding calendar items to display a monthly view by specifying http://laphroaig/public/corporate/calendar?view=monthly in your browser. If you look closely at your status bar when you're running OWA, you see that it, too, uses many parameters to drive different functionality. You can find the commands and their parameters in the WSS Software Development Kit (SDK).
Later, I explain how you can easily reuse this default OWA processing inside your Web pages. First, however, let's see how you can customize the default processing to offer the end user a different experience from the default. You can customize the default processing in two ways: by setting a default document on a folder and by implementing WSS Forms.
Changing the Default OWA Processing
Folder home pages have been available in Outlook since Outlook 98 introduced the Outlook Today page. Outlook 2000 users who have the appropriate permissions can associate a folder home page with any private or public folder. Folder home pages take advantage of the HTML support in Outlook and render HTML and ASP pages in the Outlook View pane when a user accesses a folder. This process overrides the default processing, which would usually just list the folder's contents. Only Outlook clients use a folder home page, and the existence of a folder home page doesn't affect the folder display when a user accesses the folder with OWA.
However, you can implement the same functionality for OWA clients that Outlook clients have, although no direct UI exists for doing so. The WSS uses properties extensively to describe and persist information about the folders and items in the Store. Items in the WSS have many built-in properties, and you can add properties to any item to suit the needs of your applications. For example, an application storing information about employees can store the user's company car as a custom property of the employee contact item. When a user uses the HTTP protocol to access a folder item, Exchange checks whether the DAV:defaultdocument property is set on the folder. If the value of this property is set to a URL that points to an item in the WSS, Exchange processes the resulting item instead of using the default OWA processing. Typically, the URL points to an HTML or ASP item, which Exchange then renders and displays on the browser client. You can use this method to implement folder home pages for OWA clients.
You can set the DAV:defaultdocument property several ways (e.g., ActiveX Data Objects—ADO, WebDAV). My preference is to execute an install.asp file in the folder that uses ADO to set the value of the property to default.asp (or .htm). This method reflects how IIS implements default pages. For example, if you want to set the default document on http://lahproaig/public/corporate, you physically place install.asp and default.asp into this folder. Then, you type the URL http://laphroaig/public/corporate/install.asp into your browser. (Before you can set the document, you must have previously enabled script access on the /public/corporate virtual directory by using either the Microsoft Management Console—MMC—Exchange System Manager or the MMC Internet Services Manager snap-in. The Web-exclusive sidebar "Enabling Script Access to IIS Virtual Directories," InstantDoc ID 19718, http://www.exchangeadmin.com, explains how to enable scripts. The Exchange System Manager lets you set access only at the public level, whereas the Internet Services Manager lets you set it at the subfolder level.) Web Listing 1 on the Exchange Administrator Web site shows the install.asp code. After install.asp executes, the contents of default.asp display anytime someone references the URL http://laphroaig/public/corporate either by browsing the public folder tree in OWA or by linking directly to the URL.
WSS Forms provide another way to change the default OWA processing. WSS Forms are adaptive HTML-based forms that Exchange 2000 can transmit to browsers when users access particular URLs. Full details about how to implement WSS Forms are outside the scope of this article, but the forms achieve similar functionality to Outlook forms. WSS Forms, however, are geared toward the Web and overcome many common issues such as adapting to different browsers and language settings. In addition, you can write WSS Forms directly from Microsoft FrontPage 2000 (or even Microsoft Visual InterDev) in the same way you can write any other Web form.
WSS Forms are datacentric; that is, the form that ultimately displays is associated with the URL that a user is requesting. The WSS contains a forms registry that holds details about which forms to use for particular URLs and types of HTTP requests (e.g., GET, PUT). In addition to registering a WSS Form for a URL, you can register WSS Forms that OWA should use when someone requests items of a particular content class. You can, therefore, use WSS Forms to build applications that reside in the WSS and to override the default OWA processing.
Let's look at a simple example. OWA supports the preview pane. When you access an item through OWA, OWA invokes the preview pane by appending a parameter to the URL of the item. For example, http://laphroaig/public/corporate/news/Today.eml?cmd=preview shows the preview pane for the item with the subject Today in the corporate/news folder. If you want to restrict access to the preview pane for items in this folder, you can register a WSS Form that displays when someone requests this URL. Figure 2 shows the preview pane before you register the WSS Form, and Figure 3 shows the preview pane after you register a WSS Form. By comparing the two figures, you can see the effect of this change. In Figure 3, the WSS Form's contents have overridden the original preview pane's contents.
Because WSS Forms are adaptive, you can change the default OWA processing for only certain types of browsers, languages, and operations. In fact, an ISP could provide a completely different OWA experience for different customers!
Reusing OWA Components in Applications
OWA delivers rich functionality out of the box that you can reuse directly inside your Web pages. Again, this functionality relies on WSS's URL-addressability and your ability to supply parameters to the URLs to affect the processing.
Implementing frames inside your Web pages is the best way to make use of OWA functionality. A frames page, also known as a frameset, is a Web page that is divided into two or more frames, each of which points to another Web page. The source of each frame is a URL that points to another Web page, thus letting one page display information from multiple sources.
A couple of examples will help explain this process. Let's say you want to brand the OWA client. You can add a brand to the OWA page simply by adding a two-frame Web page. To implement frames, you use a hierarchical set of
