Exchange Web Service vs Exchange ActiveSync (or why buy the milk when you can get the cow for free?)
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?"
Answer
Most organizations will license EAS because one or more of the following is true for them:
- 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.
- They can't use EWS as a client protocol to access their Exchange services, but EAS is available.
- 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.