Общие сведения о разработке клиента EWS для Exchange

  • Статья

Советы по разработке с использованием EWS для Exchange.

В этой статье приведены общие сведения о создании приложения веб-служб Exchange (EWS). С помощью этих сведений можно определить, подходит ли API EWS для вашего приложения и какой тип реализации клиента вам нужен. Эта статья также содержит рекомендации по созданию приложений для Office 365, Exchange Online и версий Exchange, и версий Exchange, начиная с Exchange 2007, с использованием одной базы данных кода. Кроме того, она помогает решить, для какой среды лучше разрабатывать решения — для локальных серверов Exchange Server или Exchange Online.

Подходит ли API EWS для вашего приложения?

Прежде чем приступать к созданию приложения, необходимо определить, подходит ли вам API EWS. Если вы разрабатываете решение для Exchange Server или Exchange Online, EWS предпочтительной будет технология клиентского доступа. Разработка решений клиентского доступа для версий Exchange, начиная с Exchange 2007, в основном ориентировалась на EWS. EWS используется для работы новых функций клиентского доступа, реализованных в Outlook. К последним относится отображение состояния "нет на месте" и сведений о доступности, впервые доступное в Exchange 2007, а также функции подсказок и получения помещений, представленные в Exchange 2010. И для внутренних, и для внешних партнеров, разрабатывающих клиентские приложения Exchange, это говорит в пользу обязательности вложений в EWS.

API EWS — основной API клиентского доступа для клиентских приложений Exchange. Но в некоторых случаях для разработки клиентских приложений могут пригодиться другие API Exchange. Например, Exchange ActiveSync обладает следующими преимуществами перед EWS:

  • Чтобы сделать протокол Exchange ActiveSync более компактным, проведена разметка структуры XML.
  • Exchange ActiveSync позволяет с помощью политик управлять клиентским доступом и использовать другие надежные решения для обмена мобильными сообщениями на предприятии.

Примечание.

Для разработки клиентов Exchange ActiveSync нужна лицензия. Дополнительные сведения о различиях между Exchange ActiveSync и EWS см. в статье Choosing between Exchange ActiveSync and Exchange Web Services (EWS).

MAPI RPC/HTTP — это еще один вариант для программирования клиентских приложений Exchange. Но тем не менее MAPI RPC/HTTP не обладает интуитивно понятным интерфейсом для связи между клиентами и сервером.

Дополнительные сведения о технологиях разработки для Exchange см. в статье Explore the EWS Managed API, EWS, and web services in Exchange.

Способы разработки клиента EWS

Существует несколько способов разработки для Exchange с использованием EWS. Выбор оптимального варианта зависит от платформы разработки, инструментов, доступных реализаций и требований к приложениям для организации. Для создания клиентских приложений EWS доступны четыре основных варианта:

  • управляемый API EWS;
  • Java API EWS;
  • автоматически созданные прокси EWS;
  • настраиваемый клиентский API EWS.

Управляемый API EWS

EWS Managed API является настраиваемым клиентом веб-службы. Он является стандартным API клиентского доступа для приложений .NET Framework.

Вот несколько преимуществ управляемого API EWS:

  • позволяет использовать интуитивно понятную объектную модель;
  • устраняет сложности описания служб в файлах схемы и WSDL;
  • включает в себя клиентскую бизнес-логику;
  • обрабатывает веб-запросы и веб-отклики, а также сериализацию и десериализацию объектов;
  • его поддерживает корпорация Майкрософт.

Обратите внимание, что управляемый API EWS — не полное решение. В управляемом API EWS не реализованы некоторые функции. Несмотря на то что управляемый API EWS не обладает всеми функциями EWS, он может оказаться лучшим вариантом для разработки клиентских приложений по следующим причинам:

  • для разработки можно использовать .NET Framework;
  • интерфейс позволяет реализовать автообнаружение в дополнение к большинству элементов объектной модели EWS;
  • он реализует клиентскую бизнес-логику для работы с EWS в классе ExchangeService.

API веб-службы EWS может подойти вам больше, чем управляемый API EWS, по одной из следующих причин:

  • ваше приложение не использует .NET Framework;
  • вы не хотите распространять сборку управляемого API EWS;
  • для приложения требуются функции, не доступные в управляемом API EWS.

Дополнительные сведения см. в статье Начало работы с клиентскими приложениями управляемого API EWS.

Примечание.

Управляемое API EWS теперь доступно в качестве проекта с открытым кодом на GitHub. Вы можете использовать библиотеку открытого кода, чтобы:

  • добавлять исправления ошибок и улучшения в API;
  • получать исправления ошибок и улучшения до того, как они станут доступны в официальном выпуске;
  • получать доступ к самой полной и актуальной реализации API, которую можно использовать для справки или для создания новых библиотек на новых платформах.

Мы будем рады вашему вкладу в GitHub.

Java API веб-служб EWS

Java API EWS — это проект с открытым исходным кодом на сайте GitHub, который сообщество может обновлять и расширять. Стилистически он похож на EWS Managed API и использует сетевые запросы и ответы EWS SOAP. Хотя с помощью Java API EWS невозможно получить доступ ко всем операциям EWS SOAP, но мы надеемся, что после недавнего создания проекта с открытым кодом сообщество поможет преодолеть это препятствие. Обратите внимание, что при наличии соответствующего контракта о поддержке служба поддержки Майкрософт поможет разобраться со всеми вопросами, связанными с протоколом SOAP EWS, но не с самим Java API EWS. Java API EWS доступен для скачивания на сайте GitHub, где члены сообщества могут внести свой вклад в его развитие.

Автоматически созданные прокси EWS

Автоматически созданные клиентские API создаются на основе определений схем WSDL и XML EWS. Генераторы клиентских объектных моделей доступны для многих языков. Как правило, автоматически созданные объектные модели управляют сериализацией и десериализацией объектов. Они не включают бизнес-логику, и процесс автоматического создания часто создает артефакты, которые делают объектную модель менее интуитивно понятной в использовании. Поддержка Exchange охватывает XML-код, отправляемый и получаемый клиентом, но не объектной моделью.

Настраиваемый клиентский API EWS

Для некоторых приложений, которые используют лишь малую часть возможностей EWS, можно создать настраиваемый клиентский API для связи с Exchange. Такой способ позволит сократить использование системных ресурсов. Это удобно для клиентов, работающих на устройствах с ограниченной памятью (например, использующих .NET Micro Framework).

Возможности клиента EWS

Независимо от выбранного варианта разработки следует учитывать, как функции EWS реализуются в клиенте. Доступность компонентов зависит от версии схемы EWS, целевой для вашего приложения. Так как схемы EWS поддерживают обратную и прямую совместимость, при создании приложения, ориентированного на более раннюю версию схемы, например Exchange Server 2007 с пакетом обновления 1 (SP1), приложение также будет работать с более поздней версией схемы, например службой Exchange Server 2013 с пакетом обновления 1 (SP1), а также с Exchange Online.

Так как функции и их обновления зависят от схемы, рекомендуем использовать наиболее раннюю базу общего кода, которая относится к тем возможностям EWS, которые нужно реализовать в клиентском приложении. Многие приложения могут работать с версией Exchange2007_SP1, потому что схема Exchange 2007 с пакетом обновления 1 содержит почти все основные возможности 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, см. в статье EWS schema versions in Exchange.

В этой статье

См. также