Partager via

Vue d’ensemble de la conception client EWS pour Exchange

  • Article

Découvrez les considérations de conception pour le développement avec EWS pour Exchange.

Cet article fournit des informations générales sur la conception d'une application Exchange Web Services (EWS). Vous pouvez utiliser ces informations pour déterminer si EWS représente une API appropriée pour votre application, et si c'est le cas, quel type de mise en œuvre du client vous devez utiliser. Cet article fournit également des informations sur les meilleures pratiques en matière de conception d'applications pouvant cibler Office 365, Exchange Online et les versions d'Exchange depuis Exchange 2007, dans une base de code, ainsi que d'importants points permettant de faire un choix entre le ciblage de serveurs Exchange locaux et le ciblage d'Exchange Online.

EWS représente-t-il une API appropriée pour votre application ?

Avant de commencer à concevoir votre application, il est important de déterminer si EWS représente l'API appropriée pour vous. Si vous développez à l'aide d'Exchange Server ou d'Exchange Online, EWS est la technologie d'accès au client privilégiée. Le développement d'accès au client pour les versions d'Exchange 0 partir d'Exchange 2007 s'est principalement concentré sur EWS. La nouvelle fonctionnalité d'accès au client implémentée dans Outlook utilise EWS, y compris les fonctionnalités Absent(e) du bureau et Disponible introduites dans Exchange 2007, et les fonctionnalités Infos-courrier et Obtenir des salles introduites dans Exchange 2010. Cela représente un investissement engagé dans EWS pour les partenaires internes et externes qui développent des applications clientes Exchange.

EWS est l'API d'accès au client principale pour vos applications clientes Exchange. Toutefois, dans certains cas, vous pouvez envisager d'utiliser d'autres API Exchange pour le développement d'applications clientes. Par exemple, Exchange ActiveSync offre les avantages suivants, contrairement à EWS :

  • La structure XML a été tokenisée pour transformer Exchange ActiveSync en un protocole plus compact.
  • ActiveSync Exchange contient un mécanisme de stratégie pour contrôler l’accès au client et fournir d’autres solutions de messagerie mobile d’entreprise robustes.

Remarque

Vous avez besoin d’une licence pour développer des clients Exchange ActiveSync. Pour en savoir plus sur les différences entre Exchange ActiveSync et EWS, voir Choisir entre Exchange ActiveSync et les Services Web Exchange (EWS).

RPC MAPI sur HTTP est une autre option de programmabilité pour les applications clientes Exchange. Toutefois, RPC MAPI sur HTTP ne fournit pas d'interface intuitive pour la communication entre les clients et le serveur.

Pour plus d'informations sur les technologies de développement Exchange, voir Explorer l'API managée EWS, EWS et les services web dans Exchange.

Options pour le développement de clients EWS

Plusieurs options sont disponibles pour le développement sur Exchange à l'aide d'EWS. La meilleure option dépend de la plateforme de développement, des outils, des implémentations disponibles et des exigences en matière d'application pour votre organisation. Les quatre options principales disponibles pour la création d'applications clientes EWS sont les suivantes :

  • API managée EWS
  • API Java EWS
  • Proxys générés automatiquement EWS
  • API cliente EWS personnalisée

API managée EWS

L'API managée EWS est un client de service web personnalisé. Il s'agit de l'API d'accès au client standard pour les applications .NET Framework.

Voici quelques-uns des avantages que représente l'utilisation de l'API managée EWS :

  • elle fournit un modèle objet intuitif ;
  • elle résume les complexités de la description de service dans les fichiers WSDL et de schéma ;
  • elle comprend une logique métier côté client ;
  • elle gère les requêtes et réponses web, ainsi que la sérialisation et désérialisation d’objet ;
  • elle est prise en charge par Microsoft.

Notez toutefois que l'API managée EWS n'est pas une solution complète. Certaines fonctionnalités ne sont pas implémentées dans l'API managée EWS. Bien qu'elle n'implémente pas toutes les fonctionnalités EWS, elle peut représenter le meilleur choix pour votre développement d'application cliente, pour les raisons suivantes :

  • vous pouvez utiliser .NET Framework pour le développement ;
  • elle implémente la découverte automatique en plus de la plupart des parties du modèle objet EWS ;
  • elle implémente la logique métier côté client pour l'utilisation d'EWS, dans la classe ExchangeService.

Vous pouvez choisir d’utiliser l’API de service web EWS au lieu de l’API managée EWS pour les raisons suivantes :

  • votre application n’utilise pas .NET Framework ;
  • vous ne voulez pas distribuer l'assembly d'API managée EWS ;
  • votre application utilise des fonctionnalités qui ne sont pas implémentées dans l'API managée EWS.

Pour plus d’informations, consultez Prise en main des applications clientes API managées EWS.

Remarque

L’API managée EWS est désormais disponible comme projet open source sur GitHub. Vous pouvez utiliser la bibliothèque open source pour :

  • Participer aux résolutions de bogues et aux améliorations de l’API.
  • obtenir des correctifs et des améliorations avant qu’ils soient disponibles dans une version officielle ;
  • Accéder à l’implémentation la plus complète et la plus à jour de l’API afin de l’utiliser comme référence ou pour créer des bibliothèques sur de nouvelles plateformes.

Vos contributions sont les bienvenues via GitHub.

API Java EWS

L'API Java EWS est un projet open source sur GitHub qui peut être mis à jour et étendu par la communauté. Elle est stylistiquement semblable à l' API managée EWS et utilise les requêtes et réponses SOAP EWS sur le réseau. Bien que vous ne puissiez pas accéder à toutes les opérations SOAP EWS à l'aide de l'API Java EWS, avec la création récente du projet open source, nous attendons que la communauté comble cette lacune. Notez que le support Microsoft, avec un contrat de support approprié, traite les questions relatives au protocole SOAP EWS, mais pas à l'API Java EWS. Cette dernière est disponible pour téléchargement et pour contribution de la communauté sur GitHub.

Proxys EWS générés automatiquement

Les API clientes générées automatiquement sont générées à partir de WSDL EWS et de définitions de schéma XML. Les générateurs de modèle objet client sont disponibles dans de nombreuses langues. En règle générale, les modèles objet générés automatiquement gèrent la sérialisation et désérialisation d'objet. Ils n'incluent pas de logique métier et le processus de génération automatique crée souvent des artefacts qui rendent le modèle objet moins intuitif lors de l'utilisation. Le support Exchange prend en charge le code XML qui est envoyé et reçu par le client, mais pas le modèle objet.

API cliente EWS personnalisée

Pour certaines applications qui utilisent un petit ensemble de fonctionnalités EWS, vous pouvez créer une API cliente personnalisée pour communiquer avec Exchange. Cela vous permet de consommer moins de ressources système. Cela est utile pour les clients qui s’exécutent sur des appareils à mémoire limitée, tels que les clients exécutant le .NET Micro Framework.

Fonctionnalités clientes EWS

Quelle que soit l'option de développement que vous choisissez, vous devez penser à la façon dont les fonctionnalités EWS sont implémentées dans votre client. La disponibilité des fonctionnalités est basée sur la version du schéma EWS ciblée par votre application. Étant donné que les schémas EWS sont compatibles en amont et en aval, si vous créez une application qui cible une version de schéma antérieure, comme Exchange Server 2007 SP1, votre application fonctionnera également sur une version de schéma ultérieure, comme le service Exchange Server 2013 SP1, ainsi qu'Exchange Online.

Étant donné que les fonctionnalités et les mises à jour de fonctionnalité sont pilotées par le schéma, nous vous recommandons d'utiliser la base de code commun la plus récente ciblant les fonctionnalités EWS que vous souhaitez mettre en œuvre dans votre application cliente. De nombreuses applications peuvent cibler la version Exchange2007_SP1, car le schéma Exchange 2007 SP1 contient presque toutes les principales fonctionnalités Exchange pour travailler avec des éléments et des dossiers dans la banque d'informations Exchange. Il est recommandé de conserver des branches de code pour chaque version de schéma EWS. Vous trouverez ci-dessous les versions de schéma actuellement disponibles.

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

Les versions de schéma sont conservées dans le type simple ExchangeVersionType.

Pour plus d'informations sur les fonctionnalités disponibles dans chaque version de schéma EWS, voir Versions de schéma EWS dans Exchange.

Dans cette section

Voir aussi