EWS evaluation criteria

Exchange

Published: July 16, 2012

Find evaluation criteria for using EWS to develop messaging and calendaring applications.

Applies to:  Exchange 2013 | Exchange Online | Exchange Server 2007 | Exchange Server 2010 | Office 365 

In this article
Functional criteria for EWS
Development criteria for EWS
Security criteria for EWS
Deployment criteria for EWS
Additional resources

Exchange Web Services (EWS) provides a set of operations that client applications use to access and manage Exchange store items. Data is sent to and from the Exchange server by means of XML that is based on a schema definition. The client application creates an XML request, submits it to the server, and receives an XML response with data that is then parsed by the client.

Note Note

EWS messages are sent by means of HTTP and HTTPS and might be blocked by Internet firewalls.

The following table lists and describes the functional criteria for EWS. For descriptions of the functional criteria, see Functional criteria in the Exchange development technology evaluation criteria descriptions article.

Table 1:  EWS functional criteria

Criterion

Description

Application function

EWS is used in applications that use messaging to send and process email messages and calendar, task, and contact information, and allow programmatic access to mailboxes, public folders, and public folder mailboxes inversions of Exchange starting with Exchange 2007.

Availability

EWS ships with versions of Exchange starting with Exchange Server 2007. It can be used with Exchange Online as well as Exchange on-premises.

Application architectures

EWS does not restrict the client application architecture.

Remote usage

EWS is ideal for remote access to Exchange. Because EWS communicates by using HTTP and HTTPS, corporate firewalls and routers often do not require special configuration.

Major objects

EWS does not directly provide objects. You can use the .NET Framework to create objects that can consume EWS.

Data access model

EWS returns information in SOAP XML messages that contain the item data, properties, and error information.

Threading models

Application threading depends on the client, and does not affect EWS. EWS uses HTTP or HTTPS. Connection state information is not retained between transactions.

Transactions

EWS does not support transactions.

Management capabilities

EWS generates Windows Server operating system event log entries. Performance counters are available to measure the performance of EWS.

The following table lists and describes the development criteria for EWS. For descriptions of the development criteria, see Development criteria in the Exchange development technology evaluation criteria descriptions article.

Table 2:  EWS development criteria

Criterion

Description

Languages and tools

EWS is based on industry standards. Any language or tool that can send and receive SOAP XML messages can be used to develop against EWS.

Managed implementation

EWS is not a managed API. Client applications that use EWS 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

EWS can be used in scripts.

Test/debug tools

You do not need any specific debugging tools to debug applications that use EWS. For particularly difficult issues, a network monitoring tool might be helpful. You can use the Netmon.exe or Fiddler.exe tool to debug EWS.

Expert availability

It is easy to find developers who have created web service–based client applications. You can find developer support for EWS by visiting the Exchange developer forum.

Available information

Web service programming is supported in many programming environments and a variety of resources for web service client development are available. For information specific to EWS, see Web services in Exchange and the Exchange Server 2010 Web Services SDK.

Developer/deployment licensing

Refer to your Exchange and MSDN subscription licensing agreements to determine whether additional licenses are required for the computers on which your EWS applications are developed and deployed.

The following table lists and describes the security criteria for EWS. For descriptions of the security criteria, see Security criteria in the Exchange development technology evaluation criteria descriptions article.

Table 3:  EWS security criteria

Criterion

Description

Design-time permissions

You do not need any specific permissions to use EWS with a computer running Exchange. The Exchange server must be configured to allow web service access, and you must have permissions to access the data that the application will use.

Setup permissions

Because applications that use EWS run on either the client or the middle tier, you do not need any specific permissions for setup. If the Setup program makes changes in the Exchange store, the user who is running Setup must have permission to make those changes.

Run-time permissions

To use an EWS client application, the client must have a valid domain user account to access the client access server.

Built-in security features

EWS can use NTLM, Kerberos, or Basic authentication. We recommend that XML requests and responses are sent by means of SSL to encrypt any sensitive information.

Security monitoring features

Exchange servers use the Internet Information Services (IIS) security monitoring features.

The following table lists and describes the deployment criteria for EWS. For descriptions of the deployment criteria, see Deployment criteria in the Exchange development technology evaluation criteria descriptions article.

Table 4:  EWS deployment criteria

Criterion

Description

Server platform requirements

EWS must run on versions of the Windows Server operating system starting with Windows Server 2008. EWS can use functionality in versions of Exchange starting with Exchange 2007.

Client platform requirements

EWS does not restrict the application client platform.

Deployment methods

EWS client applications are deployed based on their client architecture and technology.

Deployment notes

None.

Community Additions

ADD
Show:
© 2014 Microsoft