Architectures for Exchange Web Services

Developers can choose between two architectures for Web services that access Exchange data.

In the COM-based architecture (top), clients use Simple Object Access Protocol (SOAP) messages sent over a standard protocol (typically Hypertext Transfer Protocol [HTTP]) to call a Web service that resides on the Exchange server where the data is stored. The Web service accesses the data through COM, either by calling application-specific COM components or by directly calling one of Microsoft’s COM libraries for Exchange: Collaboration Data Objects for Exchange (CDOEx) or ActiveX Data Objects (ADO).

The COM-based architecture is relatively simple because it leverages Microsoft’s Exchange libraries. In particular, CDOEx provides many functions for working with e-mail, appointments, contacts, and tasks. Clients can use Web services to call those functions remotely, something CDOEx does not support by itself. The main disadvantage of this architecture is that the Web service code must reside on the Exchange server where the data is stored. Organizations frequently partition Exchange stores across multiple servers in order to improve scalability, which means that clients of COM-based Web services face the potentially complex task of determining which Exchange server has the data they seek. In addition, if a Web service is intended to be accessed over the public Internet, the COM-based architecture requires the Exchange store itself to be on the public Internet, making it more vulnerable to outside attacks.