Exchange Developer Roadmap
With the introduction of Exchange Web Services in Microsoft Exchange Server 2007, we began to invest in a broadly capable developer interface. Exchange Web Services is the first Exchange API to expose rich Microsoft Office Outlook interoperability to any application in a strongly-typed, Internet accessible (HTTP-based) programming model. Because the Exchange Web Services interfaces are based on the HTTP, XML, SOAP, and WSDL open standards, developers are free to use any platform they choose for Exchange development and application deployment. Another great advantage of the open standards-based architecture of EWS is that there are many tools on various platforms available for creating programmatic interfaces for SOAP Web services, which makes developing against Exchange much easier than formatting and processing raw XML. In the next version of Exchange, we will continue to invest in Web services by delivering new capabilities that provide a more efficient and optimized interface for Exchange and UC developers.
Given this commitment to Web services and our goal of making Exchange Web Services the richest developer interface for Exchange, we want to enable developers to plan for the future by providing early information about some of the developer capabilities we expect to deliver in the next version of Exchange.
Here's a preview of some of the functionality that we plan to add to the next release of Exchange Web Services:
- Access to Folder Associated Items (FAI) and read/write access to user settings
- Management of Personal Distribution Lists
- Throttling capabilities that give Exchange administrators control over system resource consumption
- A powerful and easy-to-use server-to-server authentication model to enable building portals and enterprise mash-ups
- An easy-to-use Microsoft .NET API that fully wraps the Web service calls, which makes Web service development even easier
In addition to these enhancements to Exchange Web Services, we will continue to invest in transport extensibility, and Microsoft Windows PowerShell for Exchange administrative programmability.
We will also be removing duplicate legacy APIs, which we began to deemphasize in late 2005, from the next major version of Exchange. We are removing these APIs because of architectural changes we are making to improve reliability and enable Exchange innovation. Removing the legacy APIs and directing all applications through Exchange Web Services also significantly improves the interoperability of clients that are accessing Exchange data. This is because we can now ensure that all data access goes through a single business logic layer, the same business logic layer that Outlook Web Access, Exchange ActiveSync, Unified Messaging and many other Exchange components utilize. If you haven't already done so, we recommend that you use Exchange Web Services for new development that leverages Exchange.
APIs that Will Be Removed
The following table lists the APIs that we will be removing from the next version of Exchange, provides a summary of the common uses and functions of those APIs, and lists the recommended alternatives.
API |
What it does |
Recommended alternative |
Exchange WebDAV |
Provides HTTP access to data in the Exchange store. |
Exchange Web Services We have added a variety of features; such as ACL support and Public Folder access to Exchange Web Services in Exchange 2007 SP1 to replace Exchange WebDAV functionality and are continuing to invest in additional functionality in the next release of Exchange. |
Store Events |
Synchronous or asynchronous events running on the Store, either in-process (scripts via a wrapper, COM objects) or out-of-process (via COM+); includes methods such as OnSave, OnDelete, OnSyncSave, and OnSyncDelete. |
Exchange Web Services Push and Pull notifications for general asynchronous notifications and Transport agents for synchronous mail delivery event functionality. In Exchange 2007 we enabled transport rules, in addition to transport extensibility, that enable administrative control over mail flow based on sender, recipient, and message content. In the next release of Exchange, we are extending the capabilities of transport rules to enable a number of mail flow control scenarios without having to build a custom transport agent and enabling administrator-defined inbox rules that allow for control over the delivery of messages to the end user's mailbox. Synchronous events for non-mail delivery scenarios will not be supported in the next version of Exchange. Removing synchronous notifications will improve the reliability of Exchange and prevent data corruption issues that were often seen when applications did not save an item correctly during a multi-phase synchronous commit to the store. |
CDO 3.0 (CDOEx) |
Provides access to local Exchange data. |
Exchange Web Services Exchange Web Services has support for calendaring, contacts and other PIM data as strongly-typed objects. |
ExOLEDB |
Provides access to the Exchange store by using OLE DB and Active Data Objects (ADO). |
Exchange Web Services or VSAPI Exchange Web Services has support for PIM access, for antivirus solutions built on ExOleDB, the Exchange Virus Scan API (VSAPI) can be used to achieve similar results. |
APIs Moving To Extended Support
In addition to the APIs that we will be removing from the next version of Exchange, developers should be aware of the support lifecycle for several Exchange client libraries. The Exchange Server MAPI Client and Collaboration Data Object 1.2.1 (CDO 1.2.1) downloads are part of the Exchange 2003 codebase and will be moving to extended support together with Exchange 2003 early next year.
The following table lists the recommended alternatives for the APIs that will be moving into extended support.
API |
What it does |
Recommended alternative |
Exchange Server MAPI Client |
Provides server applications a MAPI runtime for accessing Exchange. Note: This is not the Outlook MAPI Client library that is included with Outlook. |
Exchange Web Services or Outlook MAPI Client library Exchange Web Services can be used to achieve much of the same functionality as the Exchange Server MAPI Client. Outlook's Exchange MAPI Store provider, available in the Outlook MAPI Client library can also be used to access an Exchange mailbox or public folder. |
Collaboration Data Objects 1.2.1 (CDO 1.2.1) |
Provides access to mail, calendar, and contacts data in Exchange. |
Exchange Web Services, Outlook Object Model, Outlook MAPI Client library Exchange Web Services should be used for general Exchange data access by services or server applications. The Outlook Object Model or Outlook MAPI Client library should be used for client applications. |
Because the Exchange Server MAPI Client and CDO 1.2.1 APIs are moving out of standard support, we no longer recommend writing new applications against these libraries. All new application development should be done against Exchange Web Services, the Outlook Object Model or the Outlook MAPI Client library.
To ease migration, the CDO 1.2.1 and Exchange MAPI client legacy libraries will remain available for download after they move to extended support. The use of these libraries against the next release of Exchange will be supported; however, these libraries will not be updated with new functionality or shipped in a 64-bit version. For new functionality and true 64-bit support, your application will have to use Exchange Web Services, the Outlook Object Model, or the Outlook MAPI Client library.
To get started with Exchange Web Services or transport extensibility, check out the Exchange 2007 SP1 SDK on MSDN, the Exchange Server Developer Center, and the Exchange Development Forums. For an in-depth reference for developing with Exchange Web Services, see Inside Microsoft Exchange Server 2007 Web Services, which was recently written by members of the development, test, and documentation teams. To learn more about the Outlook Object Model, visit the Outlook 2007 Resource Center. If you are going to be at TechEd in Orlando next month stop by and listen to our talk on migrating your application to Exchange Web Services.
Our documentation team will start publishing migration documentation in early June to help you with the transition. Keep your eye on this blog and the Exchange Developer Center in coming months for more information to help you with your migration planning. The Exchange documentation team would love to receive feedback on which type of documentation that would be most useful to you. Drop an e-mail message to esdkfb@microsoft.com with your opinions. The Exchange Web Services team would also like to hear your thoughts on what you want to see in the next release of Exchange, so drop us a message at ewsfdbck@microsoft.com.