• Article

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.