What API should I be using for new Exchange 2007 development?

[The_Exchange_Team]

This is a question that we hear frequently since we have released Exchange 2007.
And our answer has to be heard loud and clear: going forward Exchange Web Services should be the API of choice for developers.

Already  a year ago at TechEd 2006 we announced that the ExoleDB, WebDAV and CDOEx (APIs that we have shipped since Exchange 2000) would be de-emphasized in Exchange 2007. We explained that Exchange Web Services were our vision for the future of Exchange application development.  this year at TechEd we would like to reinforce that message. This way we hope you will have ample time to migrate your applications to Exchange Web Services. And we would like to invite you to give us as much feedback as possible on this new set of Exchange WebServices APIs. We want to make sure that in order to enable you to do all that the old APIs could do and do this in one consistent set of APIs that are easy to understand and provide you all you need in order to build your applications on top of Exchange.. 

In past releases deciding which Exchange API to use for a project required using a complex matrix of requirements versus feature sets to determine which API was the right choice from the smorgasbord of API offerings that we provided.  This all has changed in Exchange 2007 when we made a commitment to simplify our developer’s lives for the better.  That commitment was to develop an API that could grow to meet all of our customer’s requirements for a PIM access API.  These requirements included: full support in managed code, strongly typed PIM objects, encapsulation of complex business logic internal to Exchange, remotability, open-standards and cross-platform capable, performant and scalable. The API that we developed in response to this need was Exchange Web Services. 

As we promised with the roll-out of Exchange 2007 Web Services we are continuing to invest in making our web services a great developer API for Exchange 2007.  Our goal in Exchange 2007 RTM was to get a solid foundation in place and implement the functionality that the majority of Exchange Developers need.  We hit the mark, releasing Mail, Calendar, Task, Contact access in Exchange 2007 RTM.  With the SP1 release of Exchange Web Services (EWS) we are planning to add a whole host of great features, including Public Folder support, folder permissions support, ID conversion methods for OWA extensibility, (and one of the most exciting features for anyone developing a calendar application on Exchange) full delegate access support!  Exchange 2007 SP1 will be very exciting since it now gives Exchange developers an extremely rich array of Exchange features to leverage in building new applications that weren’t easily implemented on Exchange 2003 like complex scheduling and calendaring applications with meeting request work flow.

We highly recommend that you use Exchange Web Services for new application development and avoid ExoleDB, WebDAV and CDOEx for new development.  Give us feedback on about what you like and dislike in the API and what features you would prioritize next. We realize that building the new API set is a work in progress and we are aware that we haven’t yet implemented some of the features that you developers might need for your applications. Yet we are openly looking for your feedback knowing that that feedback will help us on prioritizing the new features we are adding.  If there is some functionality you need that isn’t yet in EWS, and neither will be there in the next release, then let us know through the Exchange Developer Blog or Exchange Developer Newsgroup, we are always reading those for the great feedback you  customers can provide us.

Some great resources to get you started with Exchange Web Services development are the Exchange Web Services MSDN reference documentation, the Exchange Developer Newsgroup, the Exchange Development Center and the Exchange Developer Blog. 

The EWS Team

[#2]

Sounds great - a really strong directional message!

Does this mean that we can look forward to Outlook moving away from MAPI?  And could this imply that Outlook will finally get the ability to concurrently connect to more than one Exchange org?

Thanks,
Chris

[#3]

An add-on to Chris Warwick's comment - what is the message for those of us who do pure MAPI development?  As long as an API cannot do what MAPI does (WebDAV with embedded messages, separate API for GAL), it will not be very useful.

[#4]

We used the "Events.exe" service since Exchange 5.5. Many of our Public Folder Scripts do things like

1. watching if a new mail arrives (Public Sub Folder_OnMessageCreated)
2. if a mail arrives it changes the Form (i.e. objMsgcopy.Type = "IPM.Note.MRS.FAX")
3. then it moves the message to an subfolder

Could you give an example how one can do this with "Web Services"? If possible with vbs. (only scripts).

[#5]

what about using CDOEXM for mailbox provisioning and mailbox moves? where's the new solution for these areas?

[#6]

Uli - For mailbox provisioning and mailbox moves, we encourage the use of the PowerShell interface to Exchange.

[#7]

Using web services requires an explicit user account to issue HTTP connections. My program is running as a service (local system) on the same Exchange server. How can I make my program work (manage users' mailbox and messages) without having a user account?

[#8]

One of my biggest beefs is this tendency for creating "new APIs" that don't cover everything that the existing APIs can do.  Instead of choosing functions that you think will make EWS desirable, start by systematically covering off the functionality of APIs you want us to ditch (eg can we do 100% of the old CDOEX operations using PowerShell/EWS?).  And work through them one API at a time.  If you selectively prioritize and cover only a third each of WebDav, Exoledb, and cdoex then some developers may need to use all five and we'll be bracing for yet another "big new thing" API that makes it even worse.  If EWS could do 100% of CDOEX operations then no one would have to straddle EWS and CDOEX.  You could even consider implementing a new version of CDOEX that layers on EWS so legacy code could keep working without having to maintain CDOEX anymore.

BTW, ExchangeShell and the EMC philosophy of only providing GUIs for PowerShell/ExchangeShell capable operations is great.  But the person who did the new OAB wizard didn't read the memo.  The window for "Select OAB Virtual Directory" definitely does not use Get-OabVirtualDirectory.  It becomes obvious if you bring down one of your CAS servers.

[#9]

My C# app does mailbox provisioning and has to be able to connect to 2000, 2003, and now 2007.  I'm currently using CDOEXM to connect to the first two versions, but now how am I supposed to connect to 2007?  PowerShell?  WebService?

[#10]

Sub: Backup/Restore of Exchange 2K7 using Exchange API

Hello,

I am writing an application using Exchange APIs to backup/restore the Exchange 2K7. I am able to backup the files but the 'HrESERestoreComplete' API fails during restore.

Any help in this matter is highly appreciated.

Thanks in advance.

Thanks and Regards,

Zuber

[#11]

I'm going to try to answer a couple of post questions here.  
Chris, Outlook is using Exchange Web Services today for Availability Service, OOF, and AutoDiscover functionality.

Nate, we would love the MAPI developers out there to give us feedback on what you are currently doing in MAPI that you can't do in EWS.  It is true we do not have a separate API for GAL, but we do expose the most important GAL functionality (ResolveNames/ExpandDL).  

ResolveNames will retrieve detailed GAL information about a user, similar to the old GalFind OWA URL.  You can use EWS to access embedded messages.

Karsten, you could use Exchange Web Services to register for a new mail notification on a public folder (coming soon in SP1) and then asynchronously change the message type.  However, I would recommend using the Transport APIs for this functionality since they will fire before the item even gets delivered to the folder and will be more efficient in this specific scenario.

Uli, CDOEXM is not supported in Exchange 2007, you will need to use the Exchange PowerShell.

Stanley, you will need a domain account of some sort, either computer or user account to access Exchange Web Services.

Arthur, I understand your sentiments, and our goal with Exchange Web Services is to create an API that does not require you to "straddle" multiple APIs.  EWS may not do 100% of what each of those individual APIs did in Exchange 2007, but as we are showing in SP1 we are committed to making sure that we understand and address the gaps (by cateloging at an API by API level as you suggest by the way) that are important to our developers.  You can help us out with this effort by putting your vote in for the functionality you'd like to see added in Exchange Web Services.  Post your request on the blog, or in our TechCenter newsgroup:http://msdn2.microsoft.com/en-us/exchange/default.aspx

Rob,
Yep, you'll need to use Powershell instead of CDOEXM to connect to Exchange 2007.

[#12]

Most of my customers are still on 2003, one huge customer moved from 5.5 to 2000 2 months ago. Dont have even a single customer using 2007 yet.

Is Microsoft going to provide web service implementation (optional install) for Exchange 2000 and 2003 ? If you are not, then I would rather wait until all my customers migrate to 2007.

As one reader wrote you guys need to stop releasing APIs under such regularity.

[#13]

Hi Alexei,
If your clients are on Exchange 2000/20003 they will not be able to use Exchange Web Services.  We do understand that releasing new APIs can be painful to customers, one reason why we have not significantly change our APIs since 2000.  However, developing our web services architecture and API allowed us to give our customers a really great developer experience with full managed code support, unified PIM access, business logic encapsulation, middle-tier architecture and full remotability-a trade-off that based on customer feedback we we felt was well worth introducing a new API.