For the WCF Exchange Server mail transport, a WCF endpoint is represented by the combination of a WCF binding and the endpoint address. The binding specifies the parameters that are used for communication. It represents a collection of binding elements that includes a transport binding element, an encoding binding element, and a security binding element. For applications that use the mail transport, these elements are defined as follows:
Instead of instantiating a set of binding elements within a CustomBinding object, applications can create a predefined collection of binding elements by using a class that is derived from the MailBindingBase object. In addition to the e-mail transport binding element, this class includes a text encoding binding element and optional message security.
Messages are included in the body of the e-mail message or sent as an attachment. The Subject line of the message contains the channel name. The message is identified with a custom WCF e-mail channel stamp that is provided by the message class used by Exchange Server.
Sending Messages
When an application sends a message, it calls the Send method on the current output channel, which must be open. The output channel serializes the message to a string and creates the message in the Drafts folder. It sets the appropriate values in the e-mail fields. When the message has been created, it is moved into the Outbox. This occurs through CEMAPI on the device or through Exchange Web Services on the desktop. On the device, messages in the Outbox are synchronized with other outgoing messages, as defined by ActiveSync.
Receiving Messages
When an application that is based on the WCF Exchange Server mail transport receives a message, the following process occurs:
-
The application opens the input channel.
-
The input channel calls the Receive method to begin to listen for messages.
-
When the Exchange e-mail server receives a message that has the WCF e-mail channel stamp, it automatically routes the message into the Service E-mail folder, which is at the same level as the Inbox.
.gif "Note") Note: |
|---|
| If the Exchange e-mail server has not been configured to route WCF Exchange Server service mail into the Service E-mail folder, it uses the Inbox instead. |
-
The input channel that is listening for the new mail event checks each message that arrives in the Service E-mail or Inbox folder.
The input channel blocks the code while it is listening for messages.
-
If the input channel matches the specific channel name in the message, it retrieves the message and unblocks the code.
You can call the Receive method for multiple input channels that are built on the same transport. Blocking occurs only when Receive is called for the second time on the same input channel on the same thread.
| Note: |
|---|
| Only one input channel can be associated with each channel listener. A second call to the AcceptChannel method on a channel listener will not return until the first input channel closes. |
For greater flexibility, the e-mail transport can be configured to handle messages of various sizes in different ways. For example, messages can be sent as attachments or in the message body based on their size. Larger messages might not be downloaded fully during the initial synchronization. On the device, messages in the Service E-mail or Inbox folder are synchronized with other incoming messages, as defined by Microsoft ActiveSync.
| Note: |
|---|
| For the device, the ActiveSync e-mail synchronization settings control the maximum size of each message that is initially downloaded to the device. If a message exceeds this size, only a part of the message body is downloaded initially. If a message is partially downloaded and a channel listener is waiting for the message, the transport marks the message to indicate that it has to be downloaded in its entirety. The full message is downloaded at the next synchronization session. |
When receiving a message, you can obtain the e-mail address of the sender by using the FromEmailAddress custom property in the Message class. The following example demonstrates how to use this property.
System.ServiceModel.Channels.Message m;
String senderAddress;
m = input.Receive();
senderAddress = m.Properties.ContainsKey("FromEmailAddress") Deleting Messages
The transport deletes a message as soon as the message is requested and received by the application. The process for deleting incoming messages after they are processed varies by platform.
The process for deleting incoming messages on Windows Mobile powered devices consists of the following steps:
-
The input channel retrieves a message after it calls the Receive method.
-
The mail transport issues a call to delete the message from the message store on the Windows Mobile powered device.
-
The message is deleted from the server at the next e-mail synchronization.
The process for deleting incoming messages on the desktop consists of the following steps:
-
The input channel retrieves a message after it calls the Receive method.
-
The mail transport places the message into the deleted messages cache, which is an internal cache owned by the mail transport.
-
At the next query interval, the mail transport checks the deleted messages cache.
The query interval is determined by the ServerQueryInterval property.
-
If the deleted messages cache contains any messages, the mail transport issues a query that includes a command to the server to delete the messages in the cache.
-
During the query, the mail transport checks the server events and downloads any associated messages.
-
The mail transport posts any downloaded messages to its processing cache for processing by the application.
For the desktop, the mail transport also issues a command to the server to delete messages in the deleted messages cache under the following circumstances:
These operations are synchronous; Close and Dispose block the code until the messages are deleted from the server. The time required to delete the messages can vary and depends on the number of messages that have to be deleted. If a failure occurs during this process, the transport makes several more attempts to delete the messages.
On Windows Mobile powered devices, the message store handles this function.
Messages are also deleted when they are invalid or malformed. A message that has a corrupted SOAP envelope is considered invalid and will be deleted permanently. If the subject line in the message contains bad information following the WCF e-mail channel stamp, such as an unsupported character in the channel name, it is considered to be a malformed message. Malformed messages are moved to the Deleted folder.