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.
Comments
Anonymous
May 22, 2008
Jason Henderson , the lead PM for Exchange Web Services, just put up a roadmap for the future of developmentAnonymous
May 23, 2008
Exchange Developer Roadmap - WebDAV and StoreEvents goneAnonymous
May 23, 2008
What about support for 32-bit Exchange server MAPI client on a 64-bit OS (e.g. Windows Server 2008)? Currently you can't install the existing 32-bit server MAPI bits on the the 64-bit OS. Will this be corrected?Anonymous
May 23, 2008
Hi Igor, Yes, we will be enabling this scenario, keep an eye out for the updated download, it will be coming out very soon.Anonymous
May 25, 2008
Microsoft's Push for Exchange Online Fast Guide: How to improve Outlook Web Access security Why ExchangeAnonymous
June 04, 2008
Igor - MAPI can install on Windows Server 2008 now. It was never about 64 bit - it worked on 64 bit Windows Server 2003. Read my post on the update: http://blogs.msdn.com/stephen_griffin/archive/2008/06/02/this-just-in-mapi-and-windows-server-2008-now-get-along.aspxAnonymous
June 17, 2008
Updated Exchange Developer RoadmapAnonymous
June 22, 2008
I'm a little dissapoint to see WebDAV support leaving. Is there any chance of leaving it in as extended support for another release?Anonymous
June 30, 2008
Hi Jared, No, there really is no chance that we'll be keeping DAV around in the next release. Exchange Web Services really do a great job of replacing the functionality that existed in Exchange WebDAV and has many upsides that we cannot achieve with the Exchange 2000/2003/2007 codebase that Exchange WebDAV is built on. Thanks, JasonAnonymous
July 24, 2008
Jason Henderson announced in his Exchange Developer Roadmap blog post that we are officially deprecating,Anonymous
July 24, 2008
The Exchange API-spotting blog, which is run by the Exchange MSDN content and Exchange API product Anonymous
August 21, 2008
I hope full text indexing for public folders and item level security will be included in the next Exchange. We had this functionality in Exchange 2003 but lost FTI for public folders and had to rewrite item level security for Exchange 2007 using exoledb and WebDAV. Now exoledb and webDAV are going as well. I welcome the changes but we need to be able to do the same things on the latest Exchange. What's a developer to do if the same functionality is not available?Anonymous
September 30, 2008
The Exchange Developer blog has a post   updating the future vision of Exchange development. Anonymous
October 03, 2008
What will replace Event Sinks for Sync processing in E14? Async processing with EWS may not be good enough for many enterprise apps due to the delay, so I'd like to assume that there will be something to handle Sync processing - what will it be? Sync processing is needed for data integrity and all modern databases which handle two-phase commit also support some form of trigger coding - this is why I would think that E14 would also support this. Also, if an application not owned/controlled by Microsoft or the customer updates/changes/deletes an item and EWS is used to handle changes for changes/deletes, the item may not get updated for a while and if another app tries to access that item, what happens? Is there anything you can share on what the replacement will be? I've been looking for public info on this and have not found anything yet. Any info available?Anonymous
October 06, 2008
For synchronous events on mail delivery you can use Transport Agents to intercept a message in transit before it is delivered to a mailbox. For non-mail delivery scenarios we are removing synchronous store events (OnSave/OnDelete) and replacing them to async web service events. Store reliability, scalability, and performance are affected by blocking synchronous events so moving your application to an asynchronous model should improve the overall performance characteristics of the system. If you have a specific scenario that you use syncronous events for today you can post it to the blog (with as much detail as possible) and we can give you recommendations on how you can migrate it over to EWS or Transport Agents.Anonymous
May 10, 2009
I'm part of a government department with about 14000 Exchange objects split across 2 Exchange 2007 SP1 mailbox servers (CMS + SCR). We've got a requirement to support a new application that will generate up to 40,000 calendar appointments per week across users calendars . The issue we have is that there is a specific requirement to stop our users from moving or deleting these application generated calendar appointments. We were originally looking at using Sync events to check OnDeletes to stop users from messing with these appointments, but after finding out about the future of Sync events and the possible performance and stability impact on our environment we decided to look at using the Async (event notification) method. Our problem is that developers are claiming that if we attempt to use Async the delays in polling for changes and the requirement to develop a way to get the original application to generate a new appointment means that the solution would be unmanageable and have a greater performance on the environment. What are our options here? Is there another way to stop users deleting these items? Is there anything in the pipeline for Exchange 2010 where we could programmatically set object level security for Calendar items and stop users deleting items without the need for event checking? )Anonymous
February 03, 2010
To Jason Henderson. you said: >If you have a specific scenario that you use syncronous events for today you can post it to the blog >(with as much detail as possible) and we can give you recommendations on how you can migrate it over >to EWS or Transport Agents. The scenario is: Create a global rule for all user mailboxes that will place any ingoing message from *@yahoo.com to subfolder Yahoo in user Inbox. If subfolder Yahoo does not exist, create it. We have created such application using Syncronous Store Event sink. What should we do now under Excgange 2010? Thanks in advance, Victor IvanidzeAnonymous
November 14, 2011
How to use Exchange Web Services Managed API using C++? All the tutorial in MSDN are based on .Net. Is it possible to Exchange 2010 applications using C++.