Summit 7 Team Blogs

Java Exchange Web Services API

Hark back with me to days of yore, when Lotus Notes was still a thing….

IBM Lotus (and other former competitors, such as Oracle and Zimbra) frequently got mileage from pointing out the terrible development story around contemporary versions of Exchange (I’m talking Exchange 2000/2003 here). If you wanted your applications to have first-class access to stored items, you were pretty much stuck using MAPI or Extended MAPI, an API that has been known to make grown men weep bitter tears and otherwise strong women flee the Exchange development world to take vows of poverty and silence (kinda like Notes developers, but I digress). Microsoft attempted to introduce other APIs at various times: we got WebDAV (which lasted for about 1.5 versions of Exchange before Microsoft lost interest), CDOCDOEXM, and ADSI. Each of these APIs had its own strengths and weaknesses, mostly weaknesses, so MAPI continued to rule the roost. As the primary API used by Outlook, it was really the only API we could count on Microsoft not deprecating, and it was the only way to access some types of data in the store. Luckily for mere mortals like me, legendary Outlook MVP Dimitry Streblechenko made MAPI usable with his Outlook Redemption library, but that didn’t help people who weren’t developing on Windows.

In Exchange 2007, Microsoft addressed these problems by introducing Exchange Web Services, an XML-based API that provided a standards-based way to access many of the objects that could live in Exchange databases. Over time, the Exchange team extended the API to handle new objects (including public folders, which once had their own set of APIs I forgot to mention above) and to work better as the basis for full-fledged clients, including the Entourage and Outlook for Mac clients, Windows Mail in Windows 8.x, and the Lync client. In addition to the EWS protocol specification, they also produced managed versions of the APIs; that is, API sets that could be used from managed languages such as C# and Java.

Fast forward to today, and EWS is widely used for a variety of applications. Essentially any device that can a) connect to the Internet, b) make HTTPS requests, and c) create and consume XML can use EWS, as long as you’re willing to deal with the raw request and payload formats. If you’re using Windows or Java, you could use the managed EWS APIs. However, the Java APIs have lagged in some important ways: they were licensed under a restrictive license that didn’t allow community sharing of contributions, they weren’t themselves open source, and they were not regularly updated and maintained—the last update was in January 2013. This combination made it harder than necessary to use the Java EWS APIs, so relatively few people did (with the exception of a few standouts, such as Lockheed Martin).

Last week, Microsoft announced that they’re fixing all these problems at once. Version 1.3 of the Java EWS API package is now kept at github, and Microsoft is accepting changes against that repository instead of keeping it private (or using CodePlex, for that matter). The Java EWS libraries are now under a new license, and Microsoft has committed to making more frequent updates—and if they don’t, well, the rest of us can contribute our changes back into the repository and update it ourselves.

This is good news.. but it’s also the sound of a shoe hitting the floor.

Office 365, you see, has its own set of REST APIs that provide access to items in the Exchange store (and SharePoint libraries, and, eventually, OneDrive for Business libraries, and probably other things besides). Microsoft has not officially announced any plans to deprecate EWS, and I don’t think they will for a while, but it is clear that they would prefer all of us use the shiny new Office 365 APIs whenever possible. Of course, that’s only viable if you’re writing applications that run against Office 365 clients. At least for now, if you want to write an application that targets the broadest possible installed base of mailboxes, it needs to use EWS because EWS works against both on-prem and online mailboxes. I don’t think it’s likely that EWS will stop working against Office 365 for the foreseeable future, but it’s all but certain that Microsoft isn’t going to keep investing in future enhancements to EWS. Rather than viewing this as a loss to existing EWS developers (including

Microsoft’s own APEX unit, which develops Mac Outlook, (and hurry up with the new version, guys!) it’s more accurate to think of this as a future path for people (such as APEX, which owns the iOS version of Office) who want to write apps that run against the cloud. Microsoft has a lot of reasons to incent developers to build against 365 and not against on-prem servers, and this API set is a key part of that strategy.

I could go on to talk about how the release of the new Java APIs under these conditions is a welcome sign of openness from Microsoft, or how the Exchange team has been at the forefront of releasing useful APIs for their product (compared, say, to Lync, SharePoint, or the Xbox team.. I kid, I kid), but those are topics for another post. Until then, have a look at the APIs (either Java or Office 365, doesn’t matter) and give some thought to what kinds of applications you might be interested in that could use them—I’d love to hear what you think.