Exchange Web Service vs Exchange ActiveSync (or why buy the milk when you can get the cow for free?)

Question

I have seen this question asked several times but the answers have so far been very robotic and disappointing:

What is the difference between EWS vs EAS?

Now, most sites give the following: "One is a protocol for mobile devices, the other is a web service." Well, no shit. Here's the real question:

What is stopping someone from setting up a descent library for EWS that any mobile app or OS could use instead of paying MS a per-user license fee for ActiveSync? Is EWS too expensive, since it's SOAPy instead of RESTful? Is ActiveSync doing more of the heavy lifting in terms of caching and general logic? Does EAS have some feature that EWS doesn't have (shared calendars or some such?) Is it really just a matter of mobile OSs wanting to ensure that Exchange 03 is supported?

I'm sure they each have their finer points that make them distinct, but the question that I think most people are getting at when this question gets asked is "Why should I pay for EAS if EWS can do the same thing and more if I'm willing to write the client side myself?"

Revelation

Answer 1

Most organizations will license EAS because one or more of the following is true for them:

1. They want to allow existing mobile devices (iOS, Android, etc) to access their services without requiring new software to be installed on them (EAS is supported on lots of devices). Zimbra and Kerio do this, for example.
2. They can't use EWS as a client protocol to access their Exchange services, but EAS is available.
3. They want to operate in a low-bandwidth environment and can't afford the weighty overhead of SOAP within EWS compared to the compressed WBXML of EAS.

I'd wager that #1 makes up the vast majority of them.

Aside: EAS is not RESTful. Everything goes over POST, there's no hypermedia or ability for the client to do content negotiation. It's basically session-oriented RPC, using WBXML as an encoding format and HTTP as a transmission protocol.

Ellersick

Thanks for the info. Basically I want to write an EWS app for Android and for a web-app that I contribute to. In the latter case, they are looking at EAS and i think EWS is a better fit. In the Android case, I think it's just smarter to leverage the open-ness of both Android and EWS to avoid the license (and, to sound less miserly, to avoid the need to provision the license). I didn't think EAS was RESTful, I just knew EWS wasn't. But thanks for clearing up that EAS uses WBXML. I'm inferring from your answer that as far as application-level features, EWS could replace EAS. – Revelation

Given that Android already contains a licensed implementation of EAS, could you leverage that somehow? Regardless, you're right - EWS is better suited as an application protocol. EAS is really just a synchronization protocol. – Ellersick

@Revelation so I was wondering how did things turn out for you on this project? I'm planning on doing the exact same thing for an iOS email client. the thing that scares me is that sparrow, the very popular..> – Dilatant

<.. iOS email client never supported exchange in their release, and the popular touchdown client offers its non-exchange client for free.. whereas its exchange client runs for $20! this means creating an exchange client is a big deal – Dilatant

There are a few other Exchange email clients for iOS like Mail+ for Outlook by iKonic Apps which seems to be pretty popular. There's also Exchange Mail by OKD but reviews are really bad – Brescia

Also check out this article: msdn.microsoft.com/en-us/library/exchange/… – Roebuck