• Chart: Removed and Deprecated Developer Features

Exchange 2007 offers a new developer platform that replaces a hodge-podge of APIs built on aging technologies, such as COM, with a new set built on Web services and the .NET Framework. The overhaul makes it easier for developers to use Visual Studio to build applications that run on top of Exchange. But some APIs have been dropped and others are likely to be dropped from future releases, making it necessary for developers to rewrite some existing applications.

Why Develop on Exchange?

Originally conceived as simply an e-mail server, Exchange morphed and gained new features as Microsoft competed with products such as Lotus Notes. Along the way, Microsoft added a number of features and APIs aimed at turning Exchange into a broader platform for building collaboration applications. Some examples of applications that can be built on top of Exchange include the following:

• Systems that automatically provision e-mail accounts with predefined settings
• Desktop applications that display information from Exchange, such as a user's calendar or contacts
• Custom filtering or logging of incoming e-mail messages based on the content of the message, such as an airline that routes e-mail messages from its best customers to a special set of customer service agents
• Applications that send e-mail as part of a larger workflow (such as order processing) or use incoming e-mail to initiate a workflow.

Out with the Old, in with the New

Applications built on Exchange fall into three general categories—applications that manage e-mail servers and accounts, applications that operate on messages and other mailbox contents, and applications that change the way messages are processed and routed. In all three categories, Exchange 2007 introduces new APIs built on Web services or the .NET Framework.

Management via PowerShell

In previous versions of Exchange, developers configured items such as mailboxes and public folders through a variety of APIs. Basic administration tasks could be done using Collaborative Data Objects for Exchange Management (CDOEXM), but other tasks could be accomplished only via Active Directory and its Active Directory Service Interface (ADSI). Monitoring the health and status of the server required yet another API—Windows Management Instrumentation (WMI). The lack of a consistent API made it difficult to write applications that automatically provisioned AD accounts and Exchange mailboxes with custom settings.

In Exchange 2007, all of these APIs are replaced with PowerShell (code-named Monad). PowerShell is a command-line scripting environment for developers and administrators. It uses a scripting language that is easier for administrators to understand than VBScript or JScript, and that offers developers a consistent set of APIs for configuring Exchange.

PowerShell is an undeniable improvement and offers developers a single API instead of forcing them to deal with three. However, because Exchange 2007 no longer supports CDOEXM, applications written to that API will need to be rewritten.

Working with Mailbox Contents

Developers can also write applications that access the contents of mailboxes and public folders. For example, an application to manage timesheets and billing might also need to directly access a user's calendar or task lists.

Previous versions of Exchange provided a bewildering array of options for accessing mailbox data, using differing underlying technologies and offering different features, including the following:

• Collaborative Data Objects for Exchange (CDOEX), a COM-based API used by server-based applications
• Messaging API (MAPI), a Win32-based API that supports both desktop and server applications but that is accessible only from the C programming language
• Outlook Object Model, a COM API that provides desktop applications with access to message and calendar information through Outlook but requires that Outlook be running on the system
• Web-based Distributed Authoring and Versioning (WebDAV)—a Web-based API that provides direct access to Exchange message store data via the Hypertext Transfer Protocol (HTTP)
• Exchange OLE DB Provider, a component that allows Exchange message-store data to be accessed through database-like APIs.

Exchange 2007 simplifies matters by providing a consistent set of Web services that can be used from server-based or desktop applications. Exchange Web Services (EWS) run on Exchange 2007 servers configured in the client access server role and provide the same basic functions as the existing APIs, as well as several new capabilities. Because EWS uses the Web service model, it offers better integration with Microsoft's core developer products, such as Visual Studio and the VB.NET and C# programming languages.

Key components of EWS include the following:

Autodiscovery allows the developer to provide a user's e-mail address and retrieve a URL to a client access server that can access the user's mailbox. Autodiscovery is important because it means that an application does not need to refer to a specific Exchange server. If a user's mailbox is moved to a new server, any applications that access that mailbox will continue to work.

Exchange Data Service provides core functions for accessing Exchange data, such as creating, updating, deleting, and moving messages, folders, and other items. It can also enumerate members of distribution lists and access message attachments.

Notification service allows an application to be called when changes are made to an Exchange folder, such as when new messages are received or a calendar event is changed. The application is then called, via a Web service, when the specified events occur.

Availability service provides access to a user's free/busy information.

Although EWS provides the same functionality as existing APIs, those APIs are still supported, so applications written to them will continue to work. Microsoft is warning customers and partners, however, that support for the older APIs may be dropped in the next major version of Exchange.

In addition to EWS, Exchange 2007 provides an updated set of Web Parts that allows developer to embed Outlook Web Access in SharePoint portals. The new Web Parts support OWA's new UI features that make the Web-based client more closely resemble the Outlook desktop application.

Customizing Mail Flow

Sometimes a developer wants to write an application that works on messages as they're received or moved between servers. Spam filters, for example, examine the contents of messages when they are received and either allow them to continue or redirect them to a special folder. In prior versions of Exchange, developers did this kind of routing by writing low-level code (called a protocol event sink) that was called when a message moved through the system.

With Exchange 2007, a new set of .NET APIs allows developers to create transport agents, which perform essentially the same function, but have the added advantages provided by the .NET Framework, such as automatic memory management and support for the C# and VB.NET programming languages. (Note that transport agents can run only on Exchange 2007 servers configured in the hub or gateway roles.)

Prior versions of Exchange also included a basic workflow system, composed of the Collaborative Data Objects for Exchange Workflow (CDOWF) API and a rudimentary design tool for describing how a message should be routed. Developers could use the system to write custom code that executed when a message was placed in a public folder, for example.

But recent years have brought major changes to Microsoft's workflow strategy—the Windows Workflow Foundation and SharePoint Server are now the company's preferred workflow platform and Exchange 2007 no longer supports CDOWF. Although rewriting an application can be a time-consuming process, most applications originally written to use Exchange's workflow engine are probably better suited for SharePoint Server, given SharePoint's built-in document management features.

For information on new features of Exchange 2007, see "Exchange 2007 a Boon to IT" on page 3 of the Feb. 2007 Update.