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

Question

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

What is the difference between EWS and EAS?

Now most sites provide the following: "One is a protocol for mobile devices, the other is a web service." Well, no shit. This begs the real question:

What prevents someone from creating a descent library for EWS that any mobile application or OS can use instead of paying MS for a user license for ActiveSync? EWS is too expensive, so how SOAPy instead of RESTful? Does ActiveSync do more heavy lifting in terms of caching and overall logic? Does EAS have a feature that EWS does not have (shared calendars or some?) Is this just a matter of mobile OSs that want to support Exchange 03?

I am sure that each of them has its own subtleties that make them different, but the question that I think most people get when they ask this question is “Why should I pay for EAS if EWS can do the same and more, if I’m ready to write the client side myself? "

Answer 1

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 the installation of new software (EAS is supported on multiple devices). Zimbra and Kerio do this, for example.
• They cannot use EWS as a client protocol to access their Exchange services, but EAS is available.
• They want to work in a low-bandwidth environment and cannot afford the significant SOAP overhead in EWS compared to the compressed WBXML EAS.

I would say that No. 1 is the vast majority of them.

Also: EAS is not RESTful. Everything goes through POST, there is no hypermedia or the ability for the client to negotiate content. This is basically a session RPC using WBXML as the encoding format and HTTP as the transfer protocol.