The most important difference between the desktop version of MSMQ and the Windows CE MSMQ service is that Windows CE does not provide an active directory interface. Due to the disconnected nature of Windows CE-based devices, a domain-centric model is not practical. Instead, Windows CE uses a peer-to-peer configuration where active directory is not required.
As a consequence, you cannot create public queues in Windows CE. Information about public queues is stored in active directory, and since Windows CE provides no interface for active directory, public queues are not supported. The Windows CE MSMQ service can, however, send messages to public queues located on a desktop computer or server.
Regardless of whether a queue is public or private, you must address all queues using a direct format name. A direct format name contains the machine name and physical name of the queue. Windows CE does not support PUBLIC= or PRIVATE= formats because active directory is required to resolve them to the machine on which the queue is located.
Additionally, all direct format names must be in the form DIRECT=OS:machinename[\private$]\queuename.
Direct-only format names typically require that you establish a direct connection between two computers before any message exchange can take place. Therefore, using a direct-only format can pose problems when working with two highly-mobile Windows CE–based devices, since it is unlikely that two devices would come online at the same time. Additionally, a direct TCP connection would be required between the two computers, and the routing capabilities of MSMQ servers could not be used. Moreover, the desktop application would have to be aware of the Windows CE version of MSMQ and would always have to specify the response queues used for reply messages in direct-only format. These requirements makes the direct-only queue architecture not a very convenient solution for Windows CE.
To solve this problem, Windows CE introduces the concept of an OutFRS queue. An OutFRS queue is an outgoing queue that points to a Falcon Routing Server (FRS). The target computer must be an MSMQ server capable of routing messages. It cannot be another Windows CE–based device or a desktop independent client. An OutFRS queue is specified as a direct format name in an OutFRSQueue registry value. However, the queue itself does not have to actually exist on the server because the actual destination queue is included as part of the message address and is specified in the PROPID_M_DEST_QUEUE message property, which supports messages sent to OutFRSQueue. Additionally, all administrative responses generated by MSMQ, such as acknowledgements (ACKs) and negative acknowledgements (NACKs), are automatically channeled through an OutFRS queue if a non-direct queue name is specified as an administrative queue for a message.
When a Windows CE–based device connects to an OutFRS server, messages from an outgoing OutFRS queue are moved to the server. This server is then responsible for the correct routing of the messages.
With this architecture, the following scenarios are possible:
Another aspect of the Windows CE MSMQ server programming model is that transaction support is not included. However, one special type of transaction—a single message transaction—is supported because of its ability to order messages and guarantee only a single delivery of each message.
To guarantee single, in-order delivery, you must create the queue as transactional, and messages must be sent to the queue using the MQ_SINGLE_MESSAGE transaction constant. For more information on using this constant, see MQCreateQueue Implementation.
Additional differences between the Windows CE MSMQ service and the Win32 MSMQ service include lack of support for the following features:
Additionally, only a TCP/IP network stack is supported.
Note You should avoid using MSMQ with redirected or removable file systems, since Windows CE MSMQ service provides no connection monitoring capabilities.