5.2 The OWA architecture

---

Figure 5.1 illustrates the basic components of the OWA architecture as it functions on a back-end server. If we follow the interaction between a browser and Exchange, we see the following:

• A browser issues an HTTP request: The request contains a URL that identifies the server name that will process the request. Another part of the URL identifies Exchange as the application that will eventually provide the data. As far as the browser is concerned, it is just asking a server for some data.

• The HTTP request flows back across the network to the IIS server referenced in the URL. Note that it is possible to direct OWA communications across a secure HTTPS connection rather than a standard HTTP link. You can also integrate solutions such as RSA's SecurID to increase security further, especially in the area of user authentication.

• Exchange registers itself with IIS as a valid application, so IIS knows that it should redirect any URL coming in that includes "Exchange" to the entry point for the application. In this case, the entry point is davex.dll, an ISAPI extension that includes the functions necessary to communicate with the Store. Exchange also registers Davex.dll with IIS as the component to handle all incoming requests for the Exchange application.

• Davex.dll interprets the request (open a folder, return some content from an item, etc.) and contacts the Store through the epoxy interprocess communication channel. Communication goes to the HTTP epoxy stub.

• Because the interprocess communication uses shared memory, epoxy can only operate when both the IIS and Store processes operate on the same physical computer. Each protocol has its own epoxy stub that runs in the Store process. The use of the epoxy layer removes the need for RPCs, which previous versions of OWA use for IIS Store communications. The overhead imposed by RPCs was the root cause of some scalability issues.

• The HTTP epoxy stub communicates with the general data entry point for the Store (exoledb.dll), which fetches the necessary information from the Store.

• OWA uses ExIFS if it wants to access information from the streaming file. ExIFS streams the data out straight to the browser. OWA fetches the properties for messages from the EDB file.

• OWA takes a reverse path to return the data to the browser, which sees the information coming back in its native format (HTML) across the HTTP protocol.

Figure 5.1: Outlook Web Access architecture.

Microsoft continues to work hard to improve OWA performance, and the code in Exchange 2003 is roughly 30 percent faster than Exchange 2000. Along with the new interface, the additional performance helps OWA to be a more acceptable client for many users.

OWA is a core component of Exchange, so the Exchange installation procedure automatically installs OWA onto every server. Windows 2000 servers include IIS automatically, but in line with the new philosophy for Windows of never installing a component on a server unless an application needs it, you have to install IIS on Windows 2003 servers before installing Exchange. You do not have to do anything special after the installation to enable Exchange to serve clients with OWA. The virtual root for Exchange becomes part of the base Web site on the server. If you want to disable OWA, you must disable the virtual root, but you must be aware that this action will prevent any HTTP access to any mailbox or public folder hosted on the server.

5.2.1 HTTP-DAV extensions

OWA uses HTTP-DAV as the base set of browser commands to build its functionality. In addition to the base set of HTTP 1.1 commands, DAV provides methods (commands) to:

• Manipulate files: MKCOL, COPY, MOVE, LOCK, UNLOCK

• Manipulate document properties: PROPFIND, PROPPATCH

• Perform searches: SEARCH

• Publish: SUBSCRIBE, POLL

Taken together, the additional commands enable a certain degree of document management features for browsers. HTTP-DAV is able to process files as single entities or as collections. The MKCOL command makes a collection, or selection, of objects, such as a set of files in a directory, a set of items in a folder, or it creates a folder. Being able to process collections is clearly more efficient than being required to fetch and process individual items.

Browsers traditionally process documents rather than individual attributes or properties of the document. XML describes a schema for documents, and HTTP-DAV uses the PROPFIND and PROPPATCH commands to manipulate document properties described in the schema. The PROPFIND command allows browsers to retrieve properties of documents, such as their author or subject. PROPPATCH sets values for properties, so a browser can now change the title of a document. Changing the time of an appointment provides a good example of how HTTP-DAV can manipulate properties. A number of properties need to be updated to change an appointment-the start time, end time, and perhaps the details of the appointment such as the subject and place. The PROPPATCH command is used to change the properties to update the appointment. Indeed, rich browsers are able to update the screen with the new properties without having to issue a call to the server, whereas older browsers have to click on the refresh button.

In some respects, SEARCH is the most interesting command, because it allows a browser to use SQL-type syntax to enumerate the contents of folders or the properties of an item and then receive the result of the search in the form of raw XML data that the browser can sort and view in different ways. Rich browsers use Extensible Stylesheet Language (XSL) style sheets to format the data for display. The XSL style sheet that OWA uses comes from the requested Outlook view. The server generates the view on the fly and downloads it once to the browser, which then applies the view to each page. Reach browsers do not support XSL, so their views are built with HTML tables.

The point here is that the browser does all the work to manipulate data locally once the client receives data from the server, and this is the magic that allows OWA now to support different views or sorting by columns without needing to go to the server and fetch new data after a new view or sort is requested. You can easily see XML processing in action if you expand and collapse a view, or opt to sort a view by a different field. If you elect to use a new view on a folder such as "By Conversation Topic," a slight delay may occur while the browser downloads and then sorts the data, but performance is very acceptable even for large folders. As an example, Figure 5.2 shows OWA accessing a large public folder that takes in a feed from the public msexchange mailing list on www.swynk.com. A large number of messages arrive in the folder daily-over 30,000 in a year. Even with so many items to process, the XSL and IE combination in OWA 2000 or 2003 delivers more than acceptable performance. By comparison, in Exchange 5.5, OWA refreshes data from the server each time it needs to change the way it presents data (similar to a view change), but cached XML data means that the browser can collapse or expand a view or sort data in a view without going to the server. Now, even with large folders, OWA is able to switch views almost instantly without placing any additional burden on the server.

Figure 5.2: Applying a view to a large public folder.

Note that caching does not imply that data remains for long periods on the PC. The design of OWA views data as transient and the user interface as more persistent. To accomplish this, the headers for HTML and XML data specify the "nocache" keyword to ensure that the browser does not leave user data on the PC for potential examination after a user session is over and to ensure that OWA never displays stale data. Style sheets and behaviors that influence the user interface are more persistent.

---