Exchange 的 EWS 客户端设计概述

  • 项目

了解使用 Exchange 的 EWS 进行开发的设计注意事项。

本文提供有关设计 Exchange Web 服务 (EWS) 应用程序的概述信息。 可以使用此信息来确定 EWS 是否是应用程序的正确 API，如果是，应使用哪种类型的客户端实现。 本文还提供了如何设计面向 Office 365、Exchange Online 和从 Exchange 2007 开始的 Exchange 版本的应用程序的最佳做法信息，并整合在一个代码库中，以及在面向本地 Exchange 服务器和面向 Exchange Online 之间的重要决策点。

EWS 是不是适合你的应用程序的 API？

在开始设计应用程序之前，请务必考虑 EWS 是不是适合你的 API。 如果要针对 Exchange Server 或 Exchange Online 进行开发，则 EWS 是首选的客户端访问技术。 从 Exchange 2007 开始的 Exchange 版本的客户端访问开发主要侧重于 EWS。 Outlook 中实现的新客户端访问功能使用 EWS，包括 Exchange 2007 中引入的外出 (OOF) 和空闲状态功能，以及 Exchange 2010 中引入的邮件提示和获取会议室功能。 这代表为开发 Exchange 客户端应用程序的内部和外部合作伙伴在 EWS 方面的坚定投入。

EWS 是 Exchange 客户端应用程序的主要客户端访问 API。 但是，在某些情况下，可以考虑使用其他 Exchange API 进行客户端应用程序开发。 例如，Exchange ActiveSync 比 EWS 具有以下优势：

  • XML 结构已标记化，使 Exchange ActiveSync 成为更简洁的协议。
  • Exchange ActiveSync 包含一种策略机制，用于控制客户端访问并提供其他可靠的企业移动消息传递解决方案。

注意

需要许可证才能开发 Exchange ActiveSync 客户端。 若要了解 Exchange ActiveSync 和 EWS 之间的差异，请参阅 在 Exchange ActiveSync 之间 Exchange Web 服务 (EWS) 进行选择。

MAPI RPC over HTTP 是 Exchange 客户端应用程序的另一种可编程性选项。 但是，MAPI RPC over HTTP 不提供用于在客户端和服务器之间进行通信的直观接口。

有关 Exchange 开发技术的详细信息，请参阅 了解 Exchange 中的 EWS 托管 API、EWS 和 Web 服务。

用于 EWS 客户端开发的选项

通过使用 EWS，有多个选项可用于针对 Exchange 进行开发。 最适合你的选项取决于组织的开发平台、工具、可用实现和应用程序要求。 以下是可用于构建 EWS 客户端应用程序的四个主要选项：

  • EWS Managed API
  • EWS Java API
  • EWS 自动生成代理
  • 自定义 EWS 客户端 API

EWS 托管 API

EWS 托管 API 是一个自定义 Web 服务客户端。 它是 .NET Framework 应用程序的标准客户端访问 API。

以下是使用 EWS 托管 API 的一些好处：

  • 它能提供直观的对象模型。
  • 它能简化 WSDL 和架构文件中服务说明的复杂程度。
  • 它包括客户端业务逻辑。
  • 它能处理 Web 请求和响应以及对象序列化和反序列化。
  • 它受 Microsoft 支持。

但请注意，EWS 托管 API 不是完整的解决方案。 某些功能未在 EWS 托管 API 中实现。 尽管 EWS 托管 API 未实现所有 EWS 功能，它可能仍是你进行客户端应用程序开发的最佳选择，原因如下：

  • 你可以使用 .NET Framework 进行开发。
  • 除了 EWS 对象模型的大多数部分外，它还实现自动发现。
  • 它在 ExchangeService 类中实现了客户端业务逻辑，以与 EWS 配合使用。

如果存在以下任何原因，你可以选择使用 EWS Web 服务 API 而不是 EWS 托管 API：

  • 你的应用程序不使用 .NET Framework。
  • 你不希望分发 EWS 托管 API 程序集。
  • 你的应用程序使用 EWS 托管 API 中未实现的功能。

有关详细信息，请参阅 EWS 托管 API 客户端应用程序入门。

注意

EWS 托管 API 现已作为 GitHub 上的开源项目推出。 你可以使用开源库进行以下操作：

  • 为 API 提供缺陷修复和增强功能。
  • 在修补程序和增强功能在正式的版本中可用之前获取它们。
  • 访问最全面且最新的 API 实现，将其用作参考或在新的平台上创建新库。

欢迎你通过 GitHub 做出贡献。

EWS Java API

EWS Java API 是 GitHub 上的开放源代码项目，可由社区更新和扩展。 其风格类似于 EWS 托管 API， 并且使用线路上的 EWS SOAP 请求和响应。 虽然无法通过使用 EWS Java API 访问所有EWS SOAP 操作，但随着最近创建的开放源代码项目，我们希望依靠社区来弥补这一缺陷。 请注意，如果有适当的支持协定，Microsoft 支持部门将解决与 EWS SOAP 协议 (但不是 EWS Java API 本身) 相关的任何问题。 EWS Java API 可在 GitHub 下载和进行社区贡献。

EWS 自动生成代理

自动生成的客户端 API 是根据 EWS WSDL 和 XML 架构定义生成的。 客户端对象模型生成器支持多种语言。 通常，自动生成的对象模型将管理对象序列化和反序列化。 它们不包括业务逻辑，并且自动生成过程通常会创建使对象模型使用不太直观的项目。 Exchange 支持涵盖客户端发送和接收的 XML，但不包括对象模型。

自定义 EWS 客户端 API

对于某些使用一小部分 EWS 功能的应用程序，可以创建自定义客户端 API 来与 Exchange 通信。 这使你能够消耗更少的系统资源。 这对于在内存受限设备 (例如运行 .NET Micro Framework 的客户端) 上运行的客户端非常有用。

EWS 客户端功能

无论选择哪种开发选项，都应考虑如何在客户端中实现 EWS 功能。 功能可用性基于应用程序面向的 EWS 架构版本。 由于 EWS 架构是向后和向前兼容的，因此，如果创建面向早期架构版本 (如 Exchange Server 2007 SP1) 的应用程序，则应用程序也将适用于更高版本的架构，如 Exchange Server 2013 SP1 服务以及 Exchange Online。

由于功能和功能更新由架构驱动，因此建议使用面向要在客户端应用程序中实现的 EWS 功能的最早通用代码库。 许多应用程序可以面向 Exchange2007_SP1 版本，因为 Exchange 2007 SP1 架构包含几乎所有用于处理 Exchange 存储中的项目和文件夹的核心 Exchange 功能。 建议为每个 EWS 架构版本维护代码分支。 以下是当前可用的架构版本。

  <xs:simpleType name="ExchangeVersionType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Exchange2007" />
      <xs:enumeration value="Exchange2007_SP1" />
      <xs:enumeration value="Exchange2010" />
      <xs:enumeration value="Exchange2010_SP1" />
      <xs:enumeration value="Exchange2010_SP2" />
      <xs:enumeration value="Exchange2013" />
      <xs:enumeration value="Exchange2013_SP1" />
    </xs:restriction>
  </xs:simpleType>

架构版本在 ExchangeVersionType 简单类型中进行维护。

有关每个 EWS 架构版本中可用功能的详细信息，请参阅 Exchange 中的 EWS 架构版本。

本节内容

另请参阅