Partager via

Transport de messagerie Exchange Server WCF

  • Article

Mise à jour : novembre 2007

Le transport de messagerie WCF (Windows Communication Foundation) pour Microsoft Exchange Server fournit un service en file d'attente à l'aide de points de terminaison WCF basés sur des adresses de messagerie. Cette solution permet aux applications à la fois du .NET Compact Framework et du .NET Framework d'héberger et de consommer des services Web à partir de tout ordinateur du moment que le serveur de messagerie est accessible.

Remarque :

WCF est pris en charge dans le .NET Compact Framework version 3.5 et versions ultérieures.

Cette fonctionnalité peut être utilisée pour activer divers scénarios d'application, notamment les éléments suivants :

  • Applications qui veulent renvoyer des communications sécurisées d'un site vers un serveur central et recevoir des communications sécurisées du serveur.

  • Applications qui appliquent une opération push à des données à partir d'un serveur d'entreprise vers des périphériques sur le terrain.

  • Applications d'égal à égal où deux ou plusieurs périphériques peuvent parler directement l'un à l'autre.

    Dans ces scénarios, plusieurs correspondants communiquent des informations d'état l'un à l'autre en utilisant le serveur de messagerie comme médiateur. Par exemple, dans un scénario de jeu type, un joueur envoie une invitation pour prendre part à une partie aux autres jours en fournissant à l'application des adresses de messagerie ou un alias de groupe.

  • Applications qui localisent les périphériques perdus.

  • Applications qui mettent à jour des informations de configuration pour d'autres applications en appliquant une opération push aux données vers le périphérique.

Le transport de messagerie Exchange Server WCF prend en charge deux limitations élémentaires des périphériques en clientèle : l'addressabilité et la capacité de mettre en file d'attente des données lorsque les périphériques sont hors connexion. Le nom du canal et l'adresse de messagerie constituent l'adresse du point de terminaison WCF. C'est semblable à une adresse IP et au numéro de port dans une application de socket. L'addressabilité du périphérique est gérée par l'adresse de messagerie, alors que l'addressabilité de l'instance d'application est gérée via le nom du canal d'entrée. Le protocole WS-Addressing est utilisé pour implémenter ce schéma d'adressage personnalisé.

La mise en file d'attente est prise en charge via le magasin de données local dans les périphériques Windows Mobile. Pour des informations d'ordre général sur les files d'attente WCF, consultez Vue d'ensemble des files d'attente.

Les applications basées sur le transport de messagerie Exchange Server WCF bénéficient des fonctionnalités fondamentales de WCF. WCF fournit un modèle de programmation unifié pour différents protocoles sous-jacents et transports, et sépare la logique d'application du point de terminaison WCF. Ce modèle de programmation offre plusieurs avantages, notamment la prise en charge pour différent réseaux tels que GPRS (General Packet Radio Service), Wi-Fi et tout autre réseau qui peut accéder au serveur de messagerie. Le développement d'applications à l'aide du transport de messagerie Exchange Server WCF est très semblable au développement d'applications à l'aide de canaux WCF comme le canal HTTP.

Configuration requise

Le serveur de messagerie pour les applications basées sur le transport de messagerie WCF est Exchange Server 2007. Exchange Server 2007 Service Pack 1 fournit une tâche d'administration qui vous permet de rediriger le trafic de service vers un dossier séparé pour la messagerie WCF.

Remarque :

Le trafic de service utilise la Boîte de réception s'il n'est pas redirigé.

Le transport de messagerie est pris en charge sur les périphériques et les ordinateurs de bureau.

La CE Messaging API (CEMAPI) est requise sur le périphérique pour la prise en charge de la mise en file d'attente. CEMAPI est présente sur les périphériques Windows Mobile, mais n'est pas présente sur les périphériques Windows Embedded CE.

Windows Mobile version 5.0 et versions ultérieures prennent en charge le transport de messagerie Exchange Server WCF. Dans les versions Windows Mobile antérieures à la version 5.0 (build 14847.2.0), SMS (Systems Management Server) est utilisé à la place d'une transmission de type Direct Push pour forcer la synchronisation avec le serveur de messagerie Exchange.

Remarque :

Le transport de messagerie est également pris en charge sur Windows Mobile 2003 pour Pocket PC et Windows Mobile 2003 Second Edition pour Pocket PC. Toutefois, la période de synchronisation ActiveSync planifiée pour les messages entrants ne se produit pas toujours pour les périphériques qui exécutent des versions de Windows Mobile antérieures à la version 5.0. Pour ces périphériques, nous recommandons de ne pas spécifier de délai d'expiration ou de spécifier un grand délai d'expiration lorsque vous appelez la méthode Receive. Windows Mobile 2003 pour Smartphone n'est pas pris en charge.

  • Sur l'ordinateur de bureau, la communication avec le serveur de messagerie se produit directement via les services Web Exchange Server 2007. Le bureau ne prend pas en charge la mise en file d'attente. En conséquence, l'ordinateur de bureau doit toujours être en ligne.

  • Les applications sur le bureau utilisent l'implémentation bureau de WCF.

Architecture

La couche de messagerie est basée sur l'architecture WCF de bureau standard. La couche runtime du service n'est pas présente. L'illustration suivante montre la pile du canal, les protocoles pris en charge et les éléments de liaison.

Couche de messagerie pour le transport de messagerie Exchange Server WCF

Couche de messagerie pour le transport du courrier Exchange Server

La prise en charge de la spécification WS-Security version 1.0 inclut la sécurité des messages SOAP à l'aide de certificats X.509.

La classe Message est basée sur le standard WS-Addressing. Tous les messages sont asynchrones ; ils transitent par le serveur de messagerie en allant d'un périphérique à un autre périphérique, sans voyage de retour.

La sérialisation et la désérialisation de messages sont gérées dans le runtime du .NET Compact Framework ou du .NET Framework. Côté périphérique, un sérialiseur personnalisé doit être utilisé dans l'application. Cela n'est pas nécessaire pour le bureau parce que le .NET Framework complet prend en charge la classe DataContractSerializer. Toutefois, le même sérialiseur utilisé pour les périphériques doit être utilisé sur le bureau si l'application prend en charge la communication entre les périphériques et le bureau.

Conception

Pour le transport de messagerie Exchange Server WCF, un point de terminaison WCF est représenté par la combinaison d'une liaison WCF et l'adresse de point de terminaison. La liaison spécifie les paramètres utilisés pour la communication. Elle représente une collection d'éléments de liaison qui inclut un élément de liaison de transport, un élément de liaison de codage et un élément de liaison de sécurité. Pour les applications qui utilisent le transport de messagerie, ces éléments sont définis comme suit :

Au lieu d'instancier un jeu d'éléments de liaison dans un objet CustomBinding, les applications peuvent créer une collection prédéfinie d'éléments de liaison en utilisant une classe dérivée de l'objet MailBindingBase. En plus de l'élément de liaison de transport de messagerie, cette classe inclut un élément de liaison de codage de texte et la sécurité de message facultative.

Les messages sont inclus dans le corps du message électronique ou envoyés comme pièce jointe. La ligne Objet du message contient le nom du canal. Le message est identifié avec un tampon du canal de la messagerie électronique WCF personnalisé fourni par la classe de message utilisée par Exchange Server.

Envoi des messages

Lorsqu'une application envoie un message, elle appelle la méthode Send sur le canal d'émission courant, qui doit être ouvert. Le canal de sortie sérialise le message à une chaîne et crée le message dans le dossier Brouillons. Il définit les valeurs appropriées dans les champs de messagerie électronique. Lorsque le message a été créé, il est déplacé vers la Boîte d'envoi. Cela se produit via CEMAPI sur le périphérique ou par le biais des services Web d'Exchange sur le bureau. Sur le périphérique, les messages dans la Boîte d'envoi sont synchronisés avec d'autres messages sortants, comme défini par ActiveSync.

Réception des messages

Lorsqu'une application basée sur le transport de messagerie Exchange Server WCF reçoit un message, le processus suivant se produit :

  1. L'application ouvre le canal d'entrée.

  2. Le canal d'entrée appelle la méthode Receive pour se mettre à l'écoute des messages.

  3. Lorsque le serveur de messagerie Exchange reçoit un message qui a le tampon du canal de messagerie WCF, il achemine automatiquement le message vers le dossier Service E-mail, qui est au même niveau que la Boîte de réception.

    Remarque :

    Si le serveur de messagerie Exchange n'a pas été configuré pour router les messages de service Exchange Server WCF dans le dossier Service E-mail, il utilise à la place la Boîte de réception.

  4. Le canal d'entrée qui écoute pour le nouvel événement de courrier vérifie chaque message qui arrive dans le dossier Service E-mail ou dans la Boîte de réception.

    Le canal d'entrée bloque le code pendant qu'il écoute pour les messages.

  5. Si le canal d'entrée correspond au nom du canal spécifique dans le message, il récupère le message et débloque le code.

Vous pouvez appeler la méthode Receive pour plusieurs canaux d'entrée qui reposent sur le même transport. Le blocage se produit uniquement lorsque Receive est appelé pour la deuxième fois sur le même canal d'entrée et sur le même thread.

Remarque :

Un seul canal d'entrée peut être associé à chaque écouteur de canal. Un deuxième appel à la méthode AcceptChannel sur un écouteur de canal ne retournera qu'à la fermeture du premier canal d'entrée.

Pour plus de souplesse, le transport de messagerie électronique peut être configuré pour gérer diverses façons des messages de tailles différentes. Par exemple, les messages peuvent être envoyés comme pièces jointes ou dans le corps du message en fonction de leur taille. Les plus grands messages ne peuvent pas être téléchargés complètement pendant la synchronisation initiale. Sur le périphérique, les messages dans le dossier Service E-mail ou dans la Boîte de réception sont synchronisés avec d'autres messages entrants, comme défini par Microsoft ActiveSync.

Remarque :

Pour le périphérique, les paramètres de synchronisation de la messagerie ActiveSync contrôlent la taille maximale de chaque message téléchargé initialement vers le périphérique. Si un message dépasse cette taille, seule une partie du corps du message est téléchargée dans un premier temps. Si un message est partiellement téléchargé et qu'un écouteur de canal attend ce message, le transport marque le message pour indiquer qu'il doit être téléchargé entièrement. Le message complet est téléchargé lors de la session de synchronisation suivante.

Lorsque vous recevez un message, vous pouvez obtenir l'adresse de messagerie de l'expéditeur en utilisant la propriété personnalisée FromEmailAddress dans la classe Message. L'exemple suivant montre comment utiliser cette propriété.

System.ServiceModel.Channels.Message m;
String senderAddress;
m = input.Receive();
senderAddress = m.Properties.ContainsKey("FromEmailAddress")

Suppression des messages

Le transport supprime un message dès que le message est demandé et reçu par l'application. Le processus pour supprimer des messages entrants après qu'ils ont été traités varie selon la plateforme.

Le processus pour supprimer des messages entrants sur des périphériques Windows Mobile se compose des étapes suivantes :

  1. Le canal d'entrée récupère un message après qu'il a appelé la méthode Receive.

  2. Le transport de messagerie publie un appel pour supprimer le message de la banque de messages sur le périphérique Windows Mobile.

  3. Le message est supprimé du serveur à la synchronisation de messagerie suivante.

Le processus pour supprimer des messages entrants sur le bureau se compose des étapes suivantes :

  1. Le canal d'entrée récupère un message après qu'il a appelé la méthode Receive.

  2. Le transport de messagerie place le message dans le cache des messages supprimés, qui est un cache interne propriété du transport de messagerie.

  3. À l'intervalle de requête suivant, le transport de messagerie vérifie le cache des messages supprimés.

    L'intervalle de requête est déterminé par la propriété ServerQueryInterval.

  4. Si le cache des messages supprimés contient des messages, le transport de messagerie publie une requête qui inclut une commande au serveur pour supprimer les messages dans le cache.

  5. Pendant la requête, le transport de messagerie vérifie les événements de serveur et télécharge les messages qui y associés.

  6. Le transport de messagerie publie tous les messages téléchargés dans son cache de traitement pour traitement par l'application.

Pour le bureau, le transport de messagerie publie également une commande demandant au serveur de supprimer des messages dans le cache des messages supprimés dans les circonstances suivantes :

  • Lorsque vous appelez la méthode Close sur le dernier canal d'entrée ouvert qui est associé à un transport de messagerie.

  • Lorsque vous appelez la méthode Dispose sur le transport de messagerie.

Ces opérations sont synchrones ; Close et Dispose bloque le code jusqu'à ce que les messages soient supprimés du serveur. L'heure requise pour supprimer les messages peut varier et dépend du nombre de messages qui doivent être supprimés. Si un échec se produit pendant ce processus, le transport effectue plusieurs tentatives pour supprimer les messages.

Sur les périphériques Windows Mobile, la banque de messages gère cette fonction.

Les messages sont également supprimés quand ils ne sont pas valides ou correctement formés. Un message qui a une enveloppe SOAP endommagée est considéré comme non valide et est supprimé définitivement. Si la ligne Objet du message contient des informations incorrectes après le tampon de canal de messagerie WCF, tel qu'un caractère non pris en charge dans le nom du canal, il est considéré un message incorrect. Les messages incorrects sont déplacés avers le dossier Deleted.

Paramètres par défaut

La classe MailBindingBase et les classes qui en sont dérivées représentent une collection d'éléments de liaison prédéfinis. Ces classes sont conçues pour simplifier la création de canaux d'entrée et de sortie. Dans quelques scénarios, vous pouvez devoir modifier les valeurs par défaut dans ces collections prédéfinies. Si la propriété que vous devez changer n'existe pas dans MailBindingBase ou dans la classe dérivée que vous utilisez, vous pouvez créer séparément l'élément de liaison dans un objet CustomBinding. Vous pouvez également appeler la méthode CreateBindingElements pour retourner tous les éléments de liaison dans MailBindingBase.

Par exemple, la taille maximale du message par défaut pour les messages reçus est de 65 536 octets dans la classe ExchangeWebServiceMailBinding. Vous pouvez porter la taille maximale à 100 000 octets en utilisant le code suivant pour définir la propriété MaxReceivedMessageSize.

binding = new ExchangeWebServiceMailBinding(Server, Credential, MailSecurityMode.Message);
bindingElems = binding.CreateBindingElements();
bindingElems.Find<ExchangeWebServiceMailTransportBindingElement>().MaxReceivedMessageSize = 100000;
binding = new CustomBinding(bindingElems);

Sécurité

Les applications basées sur le transport de messagerie Exchange Server WCF prennent en charge la sécurité des messages SOAP basée sur le protocole WS-Security, qui ressemble aux fonctionnalités de sécurité de bureau prises en charge pour la classe HttpTransportBindingElement. Cette fonctionnalité de sécurité compte sur les certificats X.509.

Si vous utilisez le jeu prédéfini d'éléments de liaison dans une sous-classe de l'objet MailBindingBase, la sécurité des messages est disponible mais désactivée par défaut. Pour activer la sécurité, utilisez la propriété Mode. Vous pouvez modifier l'algorithme de chiffrement par défaut à l'aide de la propriété AlgorithmSuite. Quand la sécurité est activée, Basic256Rsa15 est la valeur par défaut.

Les éléments de liaison de sécurité prises en charge sur les applications qui utilisent le transport de messagerie Exchange Server WCF sont SecurityBindingElement et AsymmetricSecurityBindingElement.

Remarque :

L'utilisation de la sécurité des messages augmente la taille de chaque message. Si vous utilisez la classe ExchangeWebServiceMailBinding, et que vos messages dépassent 45 000 octets, vous devrez peut-être augmenter la valeur de la propriété MaxReceivedMessageSize. L'exemple de code dans la section précédente montre comment augmenter la taille maximale du message.

Déploiement

Pour le déploiement de périphériques, les DLL du transport de messagerie Exchange Server WCF sont fournies dans les fichiers CAB du .NET Compact Framework pour les périphériques Windows Mobile. Les assemblys managés sont installés dans le Global Assembly Cache.

Les DLL de transport de messagerie pour le périphérique sont comme suit :

  • Microsoft.ServiceModel.Channels.Mail.dll

  • Microsoft.ServiceModel.Channels.Mail.WindowsMobile.dll

  • Netcfmail3_5.dll, qui est un wrapper natif de CEMAPI

Les DLL WCF du .NET Compact Framework doivent également être présentes sur le périphérique.

Le déploiement de bureau est géré via à le fichier d'installation .msi du .NET Compact Framework. La fonctionnalité de transport de messagerie Exchange Server WCF est installée par défaut. Les assemblys de transport de messagerie sont installés dans le Global Assembly Cache du bureau.

Les DLL de transport de messagerie Exchange Server WCF pour le bureau sont les suivantes :

  • Microsoft.ServiceModel.Channels.Mail.dll

  • Microsoft.ServiceModel.Channels.Mail.ExchangeWebService.dll

Les DLL WCF de bureau standard doivent également être présentes sur le bureau.

Voir aussi

Tâches

Procédure pas à pas : utilisation du transport de messagerie Exchange Server WCF

Autres ressources

Développement Windows Communication Foundation (WCF) et le .NET Compact Framework