Transporte de correo de Exchange Server en WCF

  • Artículo

Actualización: noviembre 2007

El transporte de correo de Windows Communication Foundation (WCF) para Microsoft Exchange Server proporciona un servicio en cola utilizando puntos finales de WCF basados en direcciones de correo electrónico. Esta solución permite a las aplicaciones de .NET Compact Framework y de .NET Framework hospedar y utilizar servicios web de cualquier equipo siempre que el servidor de correo electrónico sea accesible.

Nota:

.NET Compact Framework versión 3.5 y posteriores admiten WCF.

Esta característica se puede utilizar para habilitar diferentes escenarios de aplicación, incluidos los siguientes:

  • Aplicaciones que desean devolver comunicaciones seguras desde el campo a un servidor central y recibir comunicaciones seguras del servidor.

  • Aplicaciones que insertan datos de un servidor de la empresa en dispositivos sobre el terreno.

  • Aplicaciones del mismo nivel donde dos o más dispositivos pueden comunicarse entre sí directamente.

    En estos escenarios, varias partes se comunican entre sí información sobre el estado utilizando el servidor de correo electrónico como mediador. Por ejemplo, en un escenario de juegos típico, un jugador envía a otros jugadores una invitación para jugar proporcionando a la aplicación las direcciones de correo electrónico o un alias de grupo.

  • Aplicaciones que buscan dispositivos perdidos.

  • Aplicaciones que actualizan la información de configuración de otras aplicaciones insertando datos en el dispositivo.

El transporte de correo de Exchange Server en WCF se enfrenta a dos limitaciones básicas de los dispositivos sobre el terreno: capacidad de direccionamiento y capacidad para poner en la cola los datos cuando los dispositivos están sin conexión. El nombre del canal y la dirección de correo electrónico constituyen la dirección de punto final de WCF. Esto es similar a una dirección IP y un número de puerto en una aplicación basada en socket. La capacidad de direccionamiento del dispositivo se administra mediante la dirección de correo electrónico y la capacidad de direccionamiento de la instancia de la aplicación se administra mediante el nombre del canal de entrada. El protocolo WS-Addressing se utiliza para implementar este esquema de direccionamiento personalizado.

Se ofrece compatibilidad con las colas mediante el almacén de datos local de los dispositivos con Windows Mobile. Para obtener información general acerca de las colas de WCF, vea Información general de colas.

Las aplicaciones generadas sobre el transporte de correo de Exchange Server en WCF se benefician de las características fundamentales de WCF. WCF proporciona un modelo de programación unificado para varios protocolos y transportes subyacentes, y separa la lógica de la aplicación del punto final de WCF. Este modelo de programación proporciona varias ventajas, incluida la compatibilidad para diferentes redes como General Packet Radio Service (GPRS), Wi-Fi y otras redes que puedan tener acceso al servidor de correo electrónico. Desarrollar aplicaciones mediante el transporte de correo de Exchange Server en WCF es muy similar a desarrollar aplicaciones utilizando canales WCF, como el canal HTTP.

Requisitos

El servidor de correo electrónico de las aplicaciones basadas en el transporte de correo de WCF es Exchange Server 2007. Exchange Server 2007 Service Pack 1 dispone de una tarea administrativa que permite redirigir el tráfico del servicio a una carpeta independiente para el correo electrónico de WCF.

Nota:

El tráfico del servicio utiliza la Bandeja de entrada si no se redirige.

El transporte de correo es compatible tanto con dispositivos como con equipos de escritorio.

Para ser compatible con las colas, el dispositivo necesita la API de mensajería de CE (CEMAPI). CEMAPI está incluida en los dispositivos con Windows Mobile, pero no en los dispositivos con Windows Embedded CE.

Windows Mobile versión 5.0 y posteriores admiten el transporte de correo de Exchange Server en WCF. En las versiones de Windows Mobile anteriores a la versión 5.0 (compilación 14847.2.0), se utilizaba Systems Management Server (SMS) en lugar de la inserción directa para forzar la sincronización con el servidor de correo electrónico de Exchange.

Nota:

El transporte de correo también se admite en Windows Mobile 2003 para Pocket PC y Windows Mobile 2003 Second Edition para Pocket PC. Sin embargo, para los dispositivos que utilizan versiones de Windows Mobile anteriores a la 5.0, el período de sincronización de ActiveSync para los mensajes entrantes no siempre se tiene lugar cuando está programado. Para estos dispositivos, se recomienda no especificar un tiempo de espera, o bien especificar un tiempo de espera largo cuando se llame al método Receive. No se ofrece compatibilidad con Windows Mobile 2003 para Smartphone.

  • En el equipo de escritorio, la comunicación con el servidor de correo electrónico se realiza directamente a través de los servicios web de Exchange Server 2007. El escritorio no ofrece compatibilidad con las colas. Como resultado, el equipo de escritorio siempre debe estar en línea.

  • Las aplicaciones del escritorio utilizan la implementación de escritorio de WCF.

Arquitectura

La capa de mensajería está basada en la arquitectura de WCF de escritorio estándar. La capa del motor en tiempo de ejecución del servicio no está presente. La ilustración siguiente muestra la pila de canales, los protocolos admitidos y los elementos de enlace.

Capa de mensajería del transporte de correo de Exchange Server en WCF

La compatibilidad para la especificación WS-Security versión 1.0 incluye seguridad de mensajes SOAP mediante certificados X.509.

La clase Message se genera según la norma WS-Addressing. Todos los mensajes son asincrónicos; pasan de un dispositivo por el servidor de correo electrónico a otro dispositivo, sin viaje de retorno.

La serialización y deserialización de mensajes se administra dentro del motor en tiempo de ejecución de .NET Compact Framework o .NET Framework. En el lado del dispositivo, se debe utilizar un serializador personalizado en la aplicación. Esto no es necesario en la versión de escritorio porque la versión completa de .NET Framework admite la clase DataContractSerializer. Sin embargo, el mismo serializador que se utiliza para los dispositivos debe utilizarse en el escritorio si la aplicación admite la comunicación entre los dispositivos y el escritorio.

Diseño

Para el transporte de correo de Exchange Server en WCF, un punto final de WCF se representa mediante la combinación de un enlace de WCF y la dirección del punto final. El enlace especifica los parámetros que se utilizan para la comunicación. Representa una colección de elementos de enlace que incluye un elemento de enlace de transporte, otro de codificación y un tercero de seguridad. Para las aplicaciones que utilizan el transporte de correo, estos elementos se definen de la siguiente manera:

En lugar de crear instancias de un conjunto de elementos de enlace dentro de un objeto CustomBinding, las aplicaciones pueden crear una colección predefinida de elementos de enlace mediante una clase que se deriva del objeto MailBindingBase. Además del elemento de enlace de transporte de correo electrónico, esta clase incluye un elemento de enlace de codificación de texto y seguridad del mensaje opcional.

Los mensajes se incluyen en el cuerpo del mensaje de correo electrónico o se envían como datos adjuntos. La línea Asunto del mensaje contiene el nombre del canal. El mensaje se identifica mediante un sello de canal de correo electrónico de WCF personalizado proporcionado por la clase de mensaje utilizada por Exchange Server.

Enviar mensajes

Cuando una aplicación envía un mensaje, llama al método Send en el canal de salida actual, que debe estar abierto. El canal de salida serializa el mensaje a una cadena y crea el mensaje en la carpeta Borradores. Establece los valores adecuados en los campos de correo electrónico. Una vez creado el mensaje, se pasa a la Bandeja de salida. Esto se realiza a través de la CEMAPI del dispositivo o a través de los servicios web de Exchange del escritorio. En el dispositivo, los mensajes de la Bandeja de salida se sincronizan con otros mensajes salientes, tal y como define ActiveSync.

Recibir mensajes

Cuando una aplicación basada en el transporte de correo de Exchange Server en WCF recibe un mensaje, se produce el proceso siguiente:

  1. La aplicación abre el canal de entrada.

  2. El canal de entrada llama al método Receive para empezar a escuchar los mensajes.

  3. Cuando el servidor de correo electrónico de Exchange recibe un mensaje que tiene el sello de canal de correo electrónico de WCF, enruta automáticamente el mensaje a la carpeta Correo electrónico de servicio, que está en el mismo nivel que la Bandeja de entrada.

    Nota:

    Si el servidor de correo electrónico de Exchange no se ha configurado para enrutar correo del servicio de Exchange Server en WCF a la carpeta Correo electrónico de servicio, utiliza en su lugar la Bandeja de entrada.

  4. El canal de entrada que escucha los nuevos eventos de correo comprueba cada mensaje que llega a la carpeta Correo electrónico de servicio o Bandeja de entrada.

    El canal de entrada bloquea el código mientras está escuchando los mensajes.

  5. Si el canal de entrada coincide con el nombre de canal concreto del mensaje, recupera el mensaje y desbloquea el código.

Puede llamar al método Receive para varios canales de entrada generados en el mismo transporte. El bloqueo sólo se produce cuando se llama a Receive por segunda vez en el mismo canal de entrada en el mismo subproceso.

Nota:

Sólo se puede asociar un canal de entrada a cada agente de escucha del canal. Una segunda llamada al método AcceptChannel en un agente de escucha del canal no se devolverá hasta que el primer canal de entrada se cierre.

Para obtener mayor flexibilidad, el transporte de correo electrónico se puede configurar para que administre mensajes de varios tamaños de maneras diferentes. Por ejemplo, los mensajes se pueden enviar como datos adjuntos o en el cuerpo del mensaje en función de su tamaño. Los mensajes mayores podrían no descargarse totalmente durante la sincronización inicial. En el dispositivo, los mensajes de la carpeta Correo electrónico de servicio o Bandeja de entrada se sincroniza con otros mensajes entrantes, tal y como define Microsoft ActiveSync.

Nota:

En el dispositivo, la configuración de sincronización de correo electrónico de Microsoft ActiveSync controla el tamaño máximo de cada mensaje que se descarga inicialmente en el dispositivo. Si un mensaje supera este tamaño, inicialmente se descarga sólo una parte del cuerpo del mensaje. Si un mensaje se descarga parcialmente y un agente de escucha de canales está esperando el mensaje, el transporte marca el mensaje para indicar que se debe descargar completo. El mensaje completo se descarga en la sesión de sincronización siguiente.

Al recibir un mensaje, puede obtener la dirección de correo electrónico del remitente utilizando la propiedad personalizada FromEmailAddress en la clase Message. En el siguiente ejemplo se muestra cómo utilizar esta propiedad.

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

Eliminar mensajes

El transporte elimina un mensaje en cuanto la aplicación lo solicita y lo recibe. El proceso de eliminación de los mensajes entrantes una vez procesados varía de una plataforma a otra.

El proceso de eliminación de los mensajes entrantes en dispositivos Windows Mobile se realiza en los pasos siguientes:

  1. El canal de entrada recupera un mensaje después de llamar al método Receive.

  2. El transporte de correo emite una llamada para eliminar el mensaje del almacén de mensajes del dispositivo Windows Mobile.

  3. El mensaje se elimina del servidor en la siguiente sincronización del correo electrónico.

El proceso de eliminación de los mensajes entrantes en el escritorio consta de los pasos siguientes:

  1. El canal de entrada recupera un mensaje después de llamar al método Receive.

  2. El transporte de correo coloca el mensaje en la caché de mensajes eliminados, que es una caché interna propiedad del transporte de correo.

  3. En el siguiente intervalo de consulta, el transporte de correo comprueba la caché de mensajes eliminados.

    La propiedad ServerQueryInterval determina el intervalo de consulta.

  4. Si la caché de mensajes eliminados contiene algún mensaje, el transporte de correo emite una consulta que incluye un comando al servidor para eliminar los mensajes de la caché.

  5. Durante la consulta, el transporte de correo comprueba los eventos de servidor y descarga los mensajes asociados.

  6. El transporte de correo expone los mensajes descargados en su caché de procesamiento para que sean procesados por la aplicación.

En el escritorio, el transporte de correo emite también un comando al servidor para eliminar los mensajes de la caché de mensajes eliminados en las circunstancias siguientes:

  • Cuando se llama al método Close en el último canal de entrada que queda abierto y que está asociado a un transporte de correo.

  • Cuando se llama al método Dispose en el transporte de correo.

Estas operaciones son sincrónicas; Close y Dispose bloquean el código hasta que los mensajes se eliminan del servidor. El tiempo necesario para eliminar los mensajes puede variar y depende del número de mensajes que tengan que ser eliminados. Si se produce un error durante este proceso, el transporte realiza más intentos para eliminar los mensajes.

En dispositivos con Windows Mobile, el almacén del mensaje controla esta función.

También se eliminan los mensajes cuando no son válidos o son incorrectos. Un mensaje que tiene un sobre SOAP dañado se considera no válido y se elimina de forma permanente. Si la línea de asunto del mensaje contiene información incorrecta después del sello de canal de correo electrónico de WCF, por ejemplo, un carácter no admitido en el nombre del canal, se considera que es un mensaje incorrecto. Los mensajes incorrectos se mueven a la carpeta Eliminados.

Configuración predeterminada

La clase MailBindingBase y las clases derivadas de ella representan una colección de elementos de enlace predefinidos. Estas clases están diseñadas para facilitar la creación de canales de entrada y salida. En algunos escenarios, podría tener que cambiar los valores predeterminados de estas colecciones predefinidas. Si la propiedad que tiene que cambiar no existe en MailBindingBase ni en la clase derivada que está utilizando, puede crear el elemento de enlace por separado en un objeto CustomBinding. Alternativamente, puede llamar al método CreateBindingElements para devolver todos los elementos de enlace en MailBindingBase.

Por ejemplo, en la clase ExchangeWebServiceMailBinding, el tamaño máximo predeterminado para los mensajes recibidos es de 65.536 bytes. Puede aumentar el tamaño máximo a 100.000 bytes utilizando el código siguiente para establecer la propiedad MaxReceivedMessageSize.

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

Seguridad

Las aplicaciones basadas en el transporte de correo de Exchange Server en WCF admiten la seguridad de mensajes SOAP basada en el protocolo WS-Security, que se parece a las características de seguridad de escritorio admitidas para la clase HttpTransportBindingElement. Esta característica de seguridad utiliza certificados X.509.

Si utiliza el conjunto predefinido de elementos de enlace en una subclase del objeto MailBindingBase, la seguridad del mensaje está disponible pero deshabilitada de forma predeterminada. Para habilitar la seguridad, utilice la propiedad Mode. Puede cambiar el algoritmo de cifrado predeterminado utilizando la propiedad AlgorithmSuite. Cuando la seguridad está habilitada, Basic256Rsa15 es el valor predeterminado.

Los elementos de enlace de seguridad que se admiten en las aplicaciones que utilizan el transporte de correo de Exchange Server en WCF son SecurityBindingElement y AsymmetricSecurityBindingElement.

Nota:

Cuando se utiliza la seguridad de mensajes, aumenta el tamaño de cada mensaje. Si está utilizando la clase ExchangeWebServiceMailBinding y sus mensajes superan los 45.000 bytes, es posible que tenga que aumentar el valor de la propiedad MaxReceivedMessageSize. En el ejemplo de código de la sección anterior se muestra cómo aumentar el tamaño máximo del mensaje.

Implementación

Para la implementación en dispositivos Windows Mobile, las DLL del transporte de correo de Exchange Server en WCF se entregan en archivos CAB de .NET Compact Framework . Los ensamblados administrados se instalan en la caché de ensamblados global.

Las DLL del transporte de correo para el dispositivo son las siguientes:

  • Microsoft.ServiceModel.Channels.Mail.dll

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

  • Netcfmail3_5.dll, que es un contenedor nativo de CEMAPI

Las DLL de WCF de .NET Compact Framework también deben estar presentes en el dispositivo.

La implementación de escritorio se controla mediante el archivo de instalación de .NET Compact Framework .msi. De forma predeterminada, se instala la característica de transporte de correo de Exchange Server en WCF. Los ensamblados de transporte de correo se instalan en la caché de ensamblados global del escritorio.

Las DLL del transporte de correo de Exchange Server en WCF para el escritorio son las siguientes:

  • Microsoft.ServiceModel.Channels.Mail.dll

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

Las DLL estándar de la versión de escritorio de WCF también deben estar presentes en el escritorio.

Vea también

Tareas

Tutorial: Usar el transporte de correo de Exchange Server en WCF

Otros recursos

Desarrollo de Windows Communication Foundation (WCF) y .NET Compact Framework