Exchange Web Services Evaluation Criteria
Topic Last Modified: 2007-03-29
This topic provides information about using Exchange Web Services to develop messaging and calendaring applications. Exchange Web Services provides a set of operations used by client applications.
Caveats
EWS messages are sent by means of HTTP and HTTPS and might be blocked by Internet firewalls.
Functional Criteria
| Criteria | Exchange Web Services |
|---|---|
Application Domain |
Exchange Web Services is used in applications that use messaging to send and process e-mail, calendar, task, and contact information, as well as allow programmatic access to mailbox and public folders. |
Major Objects |
Exchange Web Services does not directly provide objects. You can use the Microsoft .NET Framework to create objects that can consume Exchange Web Services. |
Data Access Model |
Exchange Web Services returns information in Simple Object Access Protocol (SOAP) XML messages that contain the item data, properties, and error information. |
Threading Models |
Application threading depends entirely on the client, and does not affect Exchange Web Services. Exchange Web Services uses HTTP, so no connection state information is retained between transactions. |
Application Architectures |
Exchange Web Services client applications can either be Web-based or Windows GUI applications. Exchange Web Services can also be used for server-to-server communication. |
Remote Usage |
Exchange Web Services is ideal for remotely accessing Microsoft Exchange. Because Exchange Web Services communicates by using HTTP and HTTPS, corporate firewalls and routers often do not require special configuration. |
Transactions |
Exchange Web Services does not support transactions. |
Management Capabilities |
Exchange Web Services generates Microsoft Windows Server 2003 event log entries. Performance counters are available to measure the performance of Exchange Web Services. |
Availability |
Currently shipping with Microsoft Exchange Server 2007. |
Development Criteria
| Criteria | Exchange Web Services |
|---|---|
Languages and Tools |
Exchange Web Services is based on industry standards. Any language or tool that can send and receive SOAP XML messages can be used to develop against Exchange Web Services. |
Managed Implementation |
Exchange Web Services is not a managed API. Client applications that use Exchange Web Services can use managed code to consume the Web services. Managed applications typically use proxy classes generated by using tools or the System.Net.HttpWebRequest and System.Net.HttpWebResponse classes from the .NET Framework. |
Scriptable |
Exchange Web Services can be used in scripts. |
Test/Debug Tools |
No special debugging tools are required to debug applications that use Exchange Web Services. For particularly difficult issues, a network monitoring tool may prove helpful. The Netmon.exe orFiddler.exe tool can be very useful in debugging Exchange Web Services. |
Expert Availability |
It should not be difficult to find developers who have created Web service client applications. Because Exchange Web Services is new, it will be more difficult to find application developers who are familiar with developing Exchange Web Services clients. |
Available Information |
Web service programming is supported in many programming environments. Many books explain Web service client development. For information specific to Exchange Web Services, see the Exchange Server 2007 Software Development Kit (SDK), developer forums, or the Exchange Server Developer Center. |
Developer/Deployment Licensing |
Refer to your Microsoft Exchange and MSDN subscription licensing agreements to determine whether additional licenses are required for the computers on which your Exchange Web Services applications are developed and deployed. |
Security Criteria
| Criteria | Exchange Web Services (EWS) |
|---|---|
Design-Time Permissions |
No special developer permissions are required for using Exchange Web Services with a computer running Microsoft Exchange. The Exchange server must be configured to allow Web service access, and the developer must have permissions to access the data that the application will use. |
Setup Permissions |
Because applications that use Exchange Web Services run on either the client or middle tier, typically no special Exchange server permissions are needed for setup. If the Setup program makes changes in the Exchange store, the user running Setup must have the necessary permissions to make those changes. |
Run-time Permissions |
To use an Exchange Web Services client application, the client must use a valid domain account to access the computer that on which the Client Access server role is installed. |
Built-in Security Features |
Exchange Web Services can use NTLM, Kerberos, or Basic authentication. It is recommended that XML requests and responses be sent by means of SSL. |
Security Monitoring Features |
Client Access servers use the Microsoft Internet Information Services (IIS) security monitoring features. |
Deployment Criteria
| Criteria | Exchange Web Services (EWS) |
|---|---|
Server Platform Requirements |
Exchange Web Services clients can be run on any computer. |
Client Platform Requirements |
Exchange Web Services clients can be run on any computer. |
Deployment Methods |
Exchange Web Services client applications are deployed based on their client architecture and technology. The client or middle tier communicates by means of Exchange Web Services with an Exchange server. |
Deployment Notes |
None. |