14.2 Email and Calendaring
| Exchange Server, Microsoft's email and collaboration server product, stores and handles users' email messages, calendar appointments, contacts, and news postings. Before the Web and the explosion of Internet protocols, Exchange Server had only a few standards to support (RFC822 for message format and SMTP for message exchange). These standards were only supported for communicating with the outside world. To allow client access to server-stored email and calendaring information, Exchange Server instead supported Messaging API (MAPI).
In addition to Exchange and Outlook, Microsoft has had several other email clients, servers, and services including MSN mail and Hotmail. To achieve greater interoperability among its own products and services, Microsoft adopted a standard protocol (WebDAV) with a custom schema and proprietary extensions. This section focuses on how and why WebDAV was integrated into Exchange Server 2000. 14.2.1 Web and Internet Standards in ExchangeBy the time Exchange Server 5.5 was released, Exchange supported quite a few Internet standards:
Exchange Server 2000 (the release after 5.5) needed to do a better job of both Web support and Office 2000 support. According to the Exchange file-sharing vision, every user ought to have Office 2000 (with Outlook) and an email account on an Exchange server. Therefore, Exchange Public Folders were recommended as a central location for sharing documents among Office users. To achieve this vision, Office 2000 users needed to be able to save Office documents directly to an Exchange Public Folder. Public folders have some advantages over using a simple file system folder to share documents. Public folders can contain news postings, contacts, and emails, as well as Office documents, text files, and so on. Items in the folders can have metadata. Resources in public folders can be locked by a remote user. In other words, a public folder is a lot like a WebDAV collection (see Figure 14-6). Figure 14-6. Exchange server supporting how many protocols?
How was Office 2000 going to do remote authoring in public folders? POP3 and IMAP were out of the question because those protocols are limited to email usage. MAPI was rejected because the Office 2000 development schedule was tight and MAPI support would have been a lot of work for not enough benefit. HTTP was a better option, but as we know, HTTP alone doesn't solve remote authoring issues. The development schedule for Office 2000 already included plans for WebDAV support, so client implementors encouraged Exchange Server planners to add support for WebDAV as well. The biggest question was how all the objects in an Exchange server (Office documents, email, calendars, appointments, contacts, and news postings) would be represented with WebDAV. Calendars and all folders were exposed as WebDAV collections. Emails, appointments, contacts, news postings, and Office documents were exposed as regular WebDAV resources, but each had special properties. For example, an email object needs properties such as "from" address, "to" address, date sent, date received, and subject. Thousands of custom WebDAV properties were defined to hold all the metadata that can be found in an Exchange repository. 14.2.2 "Webifying" Exchange 2000One of the planned new features for Exchange 2000 was direct Web access to its folders and resources. Although at first blush it doesn't sound exciting to do a GET to an email, this functionality was useful for a number of reasons and, in fact, consistently requested by Exchange customers. First, URLs, particularly HTTP URLs, have become universal addresses. A URL is extremely portable because it includes not just the location of the resource within a repository but also the server name and even the protocol to use to access the resource. Exchange resources didn't have addresses of any kind, so HTTP URLs would be particularly useful, providing universal and interoperable addressing. HTTP URLs allowed information in Exchange to be linked into the World Wide Web. Customers were demanding this feature, with the obvious implication that if Exchange did not provide URLs, customers would have to remove important information from their Exchange servers and put that information somewhere on the Web. The Exchange designers thought even bigger than this. They aspired to make Exchange the first place users and application writers would think of storing all shared information. Often, shared information is in the format of Web pages (HTML files) and images, and these are now expected to have URLs. HTTP support allows application software developers to easily write code to add and retrieve information from a server (it's much easier than supporting MAPI). HTTP dramatically lowers barriers to custom software. For example, a cell phone that already had some HTTP support would find it relatively easy to download data from a user's calendar and automatically remind the user of appointments. Finally, customers were also demanding a Web-based GUI front end for Exchange so that users at kiosks and on the road could have full access to their inbox, navigate mail folders, send and reply to email, and delete messages. In response, Exchange developed Outlook Web Access (OWA). 14.2.3 OWAOWA was the first Microsoft client application to access Exchange 2000 data over WebDAV. (In fact, it shipped with Exchange 2000 [Microsoft00].) OWA is a Web server application that can run either directly on the Exchange server or on a separate server. It allows users at kiosks, or any computer that doesn't have a mail client installed (including Unix and Linux clients), to use a Web browser to get to their Exchange mailbox content. It's also useful when I use a computer configured to view somebody else's mail and I don't want to change the configuration. For example, when I'm at a remote site and borrow a friend's Internet-connected workstation to check my mail, I can use my friend's Web browser to do so without changing the configuration or settings of her machine. To present its Web-based GUI, OWA must of course dynamically generate Web pages that contain some of the data from a user's mailbox just enough to fill a screen, so the download is quick and the interface feels responsive to the user. This can be a lot of work for a Web application server, because as soon as the user pages down to view more email or deletes an email, the whole page must be regenerated. At least, that's how it works with IE 5.0 and earlier, as well as with Netscape clients. With IE 5.5, OWA can make the client use WebDAV. 14.2.4 How OWA Uses WebDAVWhen OWA builds a dynamic Web page for IE 5.5, it doesn't put the data in the page. Instead, it includes scripted routines for doing WebDAV PROPFIND requests to the user's mailbox. The script uses a component called XMLHTTP. As soon as IE 5.5 receives the page, it executes the script and gets the PROPFIND response. The script also includes instructions for using an XML stylesheet to convert the PROPFIND response body in XML to nicely formatted HTML. Appendix A has a much-simplified example of this kind of code.
To get the first view of a page such as a mailbox listing, the client has to make three requests instead of one:
However, once these pieces are in place, every time users scroll down in their mailbox or delete an email, the script in the page tells the client how to do another PROPFIND request to fill in the new data. With the same page framework and the same stylesheet, the new data is inserted in the page. Since all of this client processing happens faster than the full HTML could be downloaded, users see their data faster. Although OWA supports browsers that do not have XMLHTTP, it is much more efficient when XMLHTTP is available to separate data from presentation. Stylesheets can do the presentation part of the job, but there must be a way to download the data only, and that's where XMLHTTP comes in. The server running OWA sends client script code invoking the XMLHTTP object. This script causes the browser to make WebDAV requests (usually PROPFIND) to get the data in compact form in XML. Since fancy Web pages are 90 percent presentation, this can result in much more efficient browsing when the presentation is reused. A good example to illustrate this concept is the way OWA displays the user's inbox. The screen shows about 20 messages at a time. To scroll down or resort the listing of emails, Internet Explorer 4.0 has to ask the server for a whole new Web page, complete with all the presentation information, even though only a few data fields change. In contrast, Internet Explorer 5.0 is instructed to use the XMLHTTP component to make a PROPFIND request to get the first 20 emails in the inbox and then download a stylesheet to present the PROPFIND response body. When IE 5.0 users scroll down, a new PROPFIND request is made that only retrieves the new data; since the stylesheet is cached locally, it is reused. OWA servers do less processing when handling WebDAV requests, compared to integrating data into a HTML presentation. That means that OWA servers can handle many more IE 5.5 clients (and later IE versions, too, of course) than other browser versions. A data sheet on OWA performance states that before IE 5.0 features were available, "the effective number of users per server was limited by the overhead needed to support interpreted scripts in ASP and to run MAPI sessions within ASP." With IE 5.0, WebDAV, XML, and DHTML are used to increase performance. With IE 5.5, stylesheets improve performance even more (see Figure 14-7). Figure 14-7. OWA architecture.
Because IE 5.0/5.5 users consume fewer server resources, not only is their experience faster, but the server can also handle more of them.
14.2.5 Hotmail and Web InfrastructureAt the time when Exchange developers were considering all these Web features, Microsoft had recently acquired Hotmail, and the Exchange and Hotmail teams were planning how to move closer together in terms of technology and platform. Hotmail was entirely dependent on the Web from day one. The Web allowed an email service to potentially make money by showing ads to its users, which IMAP and POP3 didn't do. The Web also allowed a service like Hotmail to traverse firewalls. If a public email service were configured to use a proprietary protocol, it would never get through corporate firewalls and onto employee computer desktops. Most computer users are not savvy enough to telnet out of their corporate firewalls to a Unix telnet host and run a command-line email client to read their non-work-related email, but that's how I had to view email that arrived at my student account during work terms. The Web changed that (see Figure 14-8). Figure 14-8. Firewalls allow outgoing HTTP traffic but almost nothing else.
Many firewalls simply block traffic through almost every port, but very few firewalls block port 80 entirely. Because the Web is so key to communication, firewall administrators are forced to allow HTTP requests from inside the firewall to reach Web servers outside the firewall. HTTP responses to return through the firewall must return over the same connection. The Hotmail acquisition thus provided even more reasons to add HTTP support to Exchange server. Users became accustomed to access their email even if they were behind a firewall, and HTTP support via Outlook Web Access allowed them to do that. 14.2.6 Outlook ExpressExchange Server supported another client in addition to OWA and Outlook, and that was Outlook Express. Outlook was designed primarily for corporate use and it had to be purchased as part of the Office suite. Outlook Express was designed to be a free consumer email client, so it had much simpler functionality than Outlook. However, Outlook Express was still a real client-side application, which the user could download, install and configure, and use offline. To make it even easier to obtain, Microsoft included Outlook Express as part of Internet Explorer. In fact, since Internet Explorer shipped with Windows, Outlook Express came preinstalled for many users buying Windows computers. Outlook Express was frequently used to access MSN and Hotmail email accounts. Because Outlook Express is not a thin client, like OWA, it needs to use a data-oriented protocol so that it can populate its own GUI with data, rather than accept the formatting the server provides. MSN used IMAP as a data protocol, but Hotmail never did. Instead, to support Outlook Express, Hotmail added very basic WebDAV support. Since WebDAV used the same port, protocol, and infrastructure as HTTP, it was much easier to add and served the purpose at least as well as IMAP.
Some users who had not purchased Office or who simply preferred the simplicity of Outlook Express wanted to use Outlook Express to access their Exchange-hosted email as well as email from MSN, Hotmail, or other services. WebDAV support was needed in Exchange to handle Outlook Express, too. 14.2.7 ScalabilityA final pressure on Exchange Server developers was continual performance and scalability improvements. Customers found that in order to support 2000 to 3000 users, they had to buy two Exchange Server licenses. The real cost wasn't so much in the licensing fees but in the system administration costs to link two Exchange servers, share user addresses, manage delivery of incoming mail to the correct server, and share Public Folder content across both. HTTP/WebDAV offered the promise of handling more users than IMAP and MAPI. Both IMAP and MAPI are connection-oriented protocols, so while a user is online and has his or her email client running, the email client tries to maintain a connection to a server. Even when data isn't being exchanged, the connection is still open and the server has to remember the context for each open connection. In contrast, HTTP allows the server to respond to a request for data and close the connection. The server can quickly move on to the next request. HTTP makes it easier to load-balance client requests across a number of identical application servers (a model that was integral to the scalability of Hotmail). However, OWA requires the server to do all the presentation as well as data hosting. OWA servers could handle half as many simultaneous users as a regular IMAP/MAPI Exchange server because of the high cost of producing and transmitting presentation information. Any time the server can delegate presentation to the client and serve only data, the server should be able to move more quickly to the next client and handle more users. With WebDAV requests scripted from the OWA pages when viewed in IE and formatted by the client using stylesheets, OWA was able to delegate some of the presentation to the client and handle more IE users. 14.2.8 Integration ChallengesOne problem with implementing email and calendaring in the request/response model is that in some cases it would be very convenient for the server to be able to send the client a notification: "You have new mail" or "You have an appointment in 15 minutes." IMAP already does this perfectly well, but the approach chosen by the Exchange team was to do notification over HTTP/WebDAV and over port 80 instead so that the client didn't have to maintain a constant IMAP connection to the server. In WebDAV, frequently updated information may be retrieved through frequent PROPFIND requests, but this polling technique is prohibitively expensive in terms of server performance costs [Fielding98]. A true notification model would be much better, if the client has an address where it can be contacted with notifications. It's also possible to design a cheaper polling technique than PROPFIND, in which the client tells the server the kinds of changes it's interested in and polls to see if changes have been flagged. Clearly, WebDAV doesn't solve the notification problem adequately. Other problems were more or less easily addressed. Some examples:
14.2.9 Lessons LearnedOnce again, the characteristics that made Exchange Server and WebDAV suited for each other teach us lessons for similar applications. Web AddressesSince every object in the Exchange repository became an HTTP resource, every resource had a Web address. Web addresses are useful as universal links, easy to pass around in email and insert into files. This linked information in Exchange into the World Wide Web. Lower Application Development CostsExchange found that OWA and other applications were cheaper to develop once the Exchange repository supported HTTP. Web InfrastructureHTTP and WebDAV support allowed the Exchange server to take advantage of existing Web infrastructure. Users can use Outlook Web Access or a WebDAV client to access their Exchange Server information despite firewalls. Another benefit of the Web infrastructure comes from caching proxies. Since OWA includes images (e.g., in the toolbar), a client could download images from a cache without even hitting the OWA server. Not all resources are cachable, though. When a resource is subject to access control, the server must prevent caching to avoid breaches of confidentiality. Document-Oriented StorageLike the Photo Album service, email and calendaring already have a natural document-oriented storage model. It wasn't hard to adopt WebDAV as a standards-based mechanism to move, copy, and delete objects and manipulate properties that already fit the data model. Flexible Metadata SupportEven more than the photo album example, WebDAV's flexible metadata support was important in Exchange 2000. Several thousand properties were defined for contacts, appointments, emails, postings, forms, events, tasks, and notes, and more were defined for special folders like mailboxes, calendars, and address books. Although the underlying store already existed (and the implementation already had similar metadata support), WebDAV was a useful tool to access metadata. Using the XMLHTTP component to run PROPFIND requests, Exchange administrators and developers of custom applications can easily script Web pages to display any metadata from the store. Chapter 15 has more information on this component. XML Stylesheets Work with WebDAVExchange OWA uses XML data from WebDAV responses together with stylesheets to delegate presentation to the Web browser. Exchange isn't the only application to use this trick. Tamino XML server and Tamino WebDAV server provide a platform based on this model. Support for Remote Document ManagementTo copy, move, delete, or rename Exchange resources or create folders or resources, previously a custom application had only a couple of options. It could run on the Exchange server and use server-side APIs, but that requires administrator approval, which is difficult at sites where the servers are carefully managed or already nearing their top capacity just handling ordinary usage. The application could run remotely and use MAPI, but MAPI is complicated. Support for WebDAV greatly simplified development of remote applications, which could now put together simple HTTP requests to do many operations on resources on an Exchange 2000 server. Support for Multiple AuthorsEmail and calendaring applications are not typically designed from the ground up for multiple authors, but in fact there are quite a few scenarios in which multiple author support is necessary. Personal email folders and calendars are often shared between executives and their assistants. Group calendars may need to allow events to be authored by a number of users. WebDAV supports multiple authors, so it was able to handle even these scenarios. Stateless vs. Connection-OrientedHTTP's stateless design is a contributor to a Web server's ability to scale to handle a great number of users. Every HTTP request contains all the context needed to be able to handle the request. Every HTTP request can be dealt with by sending a single response. Once the response is sent (and potentially some data is saved), the Web server can "forget about" the event that just happened. With a connection-oriented protocol such as IMAP, the server has to maintain a connection for every active user, remember what the user is doing, and use previous messages as context for new messages. On similar machines, an HTTP server can typically handle more active users than an IMAP server can. |
EAN: N/A
Pages: 146