Introducción al diseño de EWS cliente de Exchange

Obtenga información sobre las consideraciones de diseño para desarrollar con EWS para Exchange.

Este artículo proporciona información general sobre el diseño de una aplicación Exchange Web Services (EWS). Puede utilizar esta información para determinar si EWS es la API adecuada para su aplicación y, en caso afirmativo, qué tipo de implementación de cliente debe utilizar. En este artículo también se proporciona información de procedimiento recomendado para diseñar aplicaciones destinadas a Office 365, Exchange Online y versiones de Exchange a partir de Exchange 2007, en una base de código y puntos de decisión importantes para dirigirse a servidores de Exchange locales frente a la orientación de destino Exchange Online.

¿La API EWS es la adecuada para su aplicación?

Antes de empezar a diseñar su aplicación, es importante considerar si EWS es la API adecuada para usted. Si está desarrollando en relación a Exchange Server o Exchange Online, EWS es la tecnología de acceso al cliente preferida. El desarrollo del acceso del cliente para las versiones de Exchange a partir de Exchange 2007 se ha centrado principalmente en EWS. La nueva funcionalidad de acceso al cliente que se implementa en Outlook utiliza EWS, incluyendo las características de Fuera de la Oficina (OOF) y Disponibilidad introducidas en Exchange 2007, y las funcionalidades MailTips y Get Rooms introducidas en Exchange 2010. Esto representa una inversión comprometida en el EWS para los socios internos y externos que desarrollan aplicaciones de cliente de Exchange.

EWS es la principal API de acceso al cliente para sus aplicaciones cliente de Exchange. Sin embargo, en algunos casos, podría considerar otras API de Exchange para el desarrollo de aplicaciones de cliente. Por ejemplo, Exchange ActiveSync ofrece las siguientes ventajas sobre EWS:

  • La estructura XML se ha acortado para hacer de Exchange ActiveSync un protocolo más compacto.
  • Exchange ActiveSync contiene un mecanismo de directivas para controlar el acceso de los clientes y proporcionar otras soluciones sólidas de mensajería móvil empresarial.

Nota:

Necesita una licencia para desarrollar clientes de Exchange ActiveSync. Para conocer las diferencias entre Exchange ActiveSync y EWS, consulte Diferencias entre Exchange ActiveSync y Exchange Web Services (EWS).

MAPI RPC sobre HTTP es otra opción de programación para las aplicaciones cliente de Exchange. Sin embargo, MAPI RPC sobre HTTP no proporciona una interfaz intuitiva para la comunicación entre los clientes y el servidor.

Para obtener más información sobre las tecnologías de desarrollo de Exchange, consulte Explorar la API administrada de EWS, EWS y los servicios web en Exchange.

Opciones para el desarrollo de clientes del SAT

Existen varias opciones para desarrollar en relación a Exchange mediante el uso de EWS. La mejor opción para usted dependerá de la plataforma de desarrollo, las herramientas, las implementaciones disponibles y los requisitos de aplicación de su organización. Estas son las cuatro opciones principales que están disponibles para construir aplicaciones de cliente EWS:

  • La API administrada EWS
  • La API de Java EWS
  • Los servidores proxy autogenerados por el EWS
  • Una API de cliente EWS personalizada

API administrada EWS

La API administrada de EWS es un cliente de servicio web personalizado. Es la API de acceso al cliente estándar para las aplicaciones de .NET Framework.

Las siguientes son algunas de las ventajas de utilizar la API administrada de EWS:

  • Proporciona un modelo de objetos intuitivo.
  • Abstrae las complejidades de la descripción del servicio en los archivos WSDL y de esquema.
  • Incluye la lógica de negocio del lado del cliente.
  • Maneja las peticiones y respuestas de la web y la serialización y deserialización de objetos.
  • Es compatible con Microsoft.

Tenga en cuenta, sin embargo, que la API administrada de EWS no es una solución completa. Algunas funcionalidades no están implementadas en la API administrada de EWS. Aunque la API administrada de EWS no implementa toda la funcionalidad de EWS, podría ser la mejor opción para el desarrollo de su aplicación cliente, por las siguientes razones:

  • Puede utilizar el .NET Framework para el desarrollo.
  • Implementa el Autodiscover además de la mayoría de las partes del modelo de objetos del EWS.
  • Implementa la lógica de negocio del lado del cliente para trabajar con EWS, en la clase ExchangeService.

Puede elegir utilizar la API de servicio web de EWS en lugar de la API administrada de EWS por cualquiera de las siguientes razones:

  • La aplicación no utiliza el .NET Framework.
  • No quiere distribuir el ensamblaje de la API administrada de EWS.
  • Su aplicación utiliza funciones que no están implementadas en la API administrada de EWS.

Para más información, consulte Introducción a las aplicaciones cliente de api administrada de EWS.

Nota:

La API administrada EWS ya está disponible como proyecto de código abierto en GitHub. Puede usar la biblioteca de código abierto para:

  • Contribuir con correcciones de errores y mejoras a la API.
  • Obtener correcciones y mejoras antes de que estén disponibles en una versión oficial.
  • Tener acceso a una implementación más completa y actualizada de la API, para usarla como referencia o para crear nuevas bibliotecas en nuevas plataformas.

Le agradecemos las aportaciones que realice a través de GitHub.

API Java EWS

La API Java de EWS es un proyecto de código abierto en GitHub que puede ser actualizado y ampliado por la comunidad. Es estilísticamente similar a la API administrada de EWS y utiliza las solicitudes y respuestas SOAP de EWS a través de la conexión. Aunque no se puede acceder a todas las operaciones SOAP de EWS utilizando la API Java de EWS, con la reciente creación del proyecto de código abierto, esperamos que la comunidad cubra este vacío. Tenga en cuenta que Microsoft Support, con un contrato de soporte adecuado, abordará cualquier cuestión relacionada con el protocolo SOAP de EWS, pero no con la propia API Java de EWS. La API Java de EWS está disponible para su descarga y contribución por parte de la comunidad en GitHub.

Servidores proxy autogenerados por el EWS

Las API de cliente autogeneradas se generan a partir de las definiciones del esquema WSDL y XML del EWS. Existen generadores de modelos de objetos cliente para muchos idiomas. En general, los modelos de objetos autogenerados administran la serialización y deserialización de los objetos. No incluyen la lógica de negocio y el proceso de autogeneración suele crear artefactos que hacen que el modelo de objetos sea menos intuitivo de usar. La compatibilidad con Exchange cubre el XML que envía y recibe el cliente, pero no el modelo de objetos.

API de cliente EWS personalizada

Para algunas aplicaciones que utilizan un pequeño conjunto de funciones de EWS, puede crear una API de cliente personalizada para comunicarse mediante Exchange. Esto le permite consumir menos recursos del sistema. Esto es útil para los clientes que se ejecutan en dispositivos de memoria restringida, como los clientes que ejecutan el .NET Micro Framework.

Características del cliente EWS

Independientemente de la opción de desarrollo que elija, debe tener en cuenta cómo se implementan las características del EWS en su cliente. La disponibilidad de las funciones se basa en la versión del esquema EWS al que se dirige su aplicación. Dado que los esquemas de EWS son compatibles con el pasado y el futuro, si crea una aplicación dirigida a una versión de esquema anterior, como Exchange Server 2007 SP1, su aplicación también funcionará con una versión de esquema posterior, como el servicio Exchange Server 2013 SP1, así como con Exchange Online.

Debido a que las características y las actualizaciones de las características son impulsadas por el esquema, le recomendamos que utilice la base de código común más antigua que se dirige a las características de EWS que desea implementar en su aplicación cliente. Muchas aplicaciones pueden dirigirse a la versión Exchange2007_SP1, porque el esquema de Exchange 2007 SP1 contiene casi toda la funcionalidad principal de Exchange para trabajar con elementos y carpetas en el almacén de Exchange. Le recomendamos que mantenga bifurcaciones de código para cada versión del esquema EWS. Las siguientes son las versiones del esquema que están disponibles actualmente.

  <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>

Las versiones del esquema se mantienen en el tipo simple ExchangeVersionType.

Para obtener información sobre las funciones disponibles en cada versión del esquema EWS, consulte Versiones del esquema EWS en Exchange.

En esta sección

Vea también