Microsoft Windows CE 3.0 Message Queuing Service

Over the past five years, distributed applications have become a mainstay of enterprise solution providers. As enterprise computing moves away from the desktop, developers need to provide a way for distributed applications to communicate when they are running on mobile, distant devices that may be disconnected at times from any physical network. Microsoft Message Queuing Service (MSMQ) is a communication service that provides asynchronous communications, guaranteed message delivery, efficient routing, and priority-based messaging to distributed applications.

Microsoft Message Queuing Service lets applications communicate with each other quickly and reliably, even when the applications are running at different times or across networks and systems that may be offline at the time the message is sent. To accomplish this, applications communicate by sending and receiving messages that contain text or binary data. The message passing is done by means of the MSMQ API and a message queue, without the applications having to establish or maintain a communication conduit. This means that you can create distributed applications without the programming overhead associated with creating and maintaining network connections and persistent data buffering.

This paper describes the key features of MSMQ on Microsoft Windows CE 3.0, with a comparison to the desktop-based Windows implementation, and provides a variety of message queuing application scenarios.

Windows CE MSMQ Independent Client Model

A desktop-based MSMQ configuration consists of a server, and any number of dependentand independent clients. The server provides message storing and routing, supports local and dependent clients, and maintains a public queue directory and other information services. The MSMQ server must be a Microsoft Windows NT 4.0 Server or Microsoft Windows 2000 Server platform.

Dependent clientsdo not have local storage, which means they cannot queue outgoing messages and must be connected to the server at all times. Independent clientscan store messages and can operate offline, but they cannot provide routing services. Clients, whether dependent or independent, can run on any Microsoft Windows 9x, Windows NT 4.0, or Windows 2000 platform. MSMQ on Windows CE supports independent clients only.

Windows CE-based independent clients can operate as clients of a desktop serve r—or in a peer-to peer, application-to-application configuration—without need of a server or a domain controller.

In the Windows CE independent client model, a single queue holds messages for both sending and receiving applications. This queue can be located on the same device as either the sending or receiving application, or on another device available to both applications. When the receiving application is restarted or the network connection is reestablished, the receiving application reads the messages stored in the queue.

The following illustration shows the components of the independent client architecture.

In a client/server configuration, Windows CE independent clients can send messages to desktop applications and to other Windows CE clients even when no direct connection is available, by routing messages through the server. Routing servers can also be used to deliver messages from Windows CE clients to other clients that are on a secured domain.

Windows CE-based clients do not support:

• Encryption
• Authentication
• MQMail
• Reading from remote queues
• Direct format queue names
• Directory-service interface for public queues

  Features of Windows CE MSMQ

  Windows CE-based devices operate in a wide variety of scenarios, ranging from stationary devices that are connected continuously to mobile devices that are usually disconnected even on startup. Frequently, the sending device and the receiving device run at different times. One requirement shared by virtually all Windows CE-based devices is the need for efficiency and a small memory footprint.

  The Windows CE MSMQ programming model provides the essential features of the desktop, optimized for systems that support a small number of simultaneous connections with a short code path. The entire persistent state of MSMQ is stored in the registry and the MSMQ base directory. As a result of these optimizations, MSMQ on Windows CE requires just 100–150 KB of storage.

  The following sections describe other key features of the Windows CE implementation of MSMQ.

  Message Delivery Methods

  MSMQ supports two delivery methods: expressand recoverable. Express messages are usually faster and consume fewer resources, but data loss is possible if the computer with the message queue were to fail. Recoverable messages are slower than express messages and consume more resources, but they can be recovered in the event of a system failure.

  Access to Public Queues

  A public queue is one that is registered with a directory service, such as Microsoft Active Directory™ This allows the MSMQ application to locate and open a queue anywhere within its domain. Because Windows CE does not have a directory-service interface, you cannot create public queues on a Windows CE-based client. The Windows CE MSMQ service can, however, send messages to public queues that are located on a desktop computer or server by using an OutFRS queue.

  An OutFRS queue is an outgoing queue that points to a Falcon Routing Server (FRS). The target computer must be a message queue server capable of routing messages; it cannot be another Windows CE–based device, or a desktop-independent client. An OutFRS queue is an outgoing queue that points to a Falcon Routing Server (FRS) The target computer must be a message queue server capable of routing messages; it cannot be another Windows CE–based device or a desktop-independent client. 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.

  Transactions

  Transactionalmessages can be used to pair the sending or receiving of any message with an action in another operation. Using transactional messages ensures that the unit of work is carried out as an atomic operation—that is, the operation succeeds or fails as a whole Transactional messages can also be used to ensure that a message is delivered only once, and to ensure that all messages sent from one computer to another are delivered in order. Positive and negative acknowledgments can be used to confirm that messages reached, or were retrieved from, the destination queue.

  Transaction support on Windows CE is limited to a single message transaction, which is sufficient to order messages, and to guarantee a single delivery of each message.

  Journaling

  Journaling support lets you recover from a failure that occurred anywhere in the system by creating a copy of the message at every routing or queuing point. Journaling is also valuable for applications that need to be able to audit messaging activity or confirm delivery.

  Network Tracking

  MSMQ supports instant reconnection, called Network Tracking. When a network card has been inserted or a dial-up connection has been established, there is an immediate reattempt to connect to all target computers. The information that controls how MSMQ retries failed connections is stored in the registry. This allows you to control this retry schedule and defer connection attempts until LAN hardware is actually available.

  Name Resolution

  Networking on Windows CE is slightly different from the desktop implementation, in particular, when it comes to name resolution.

  Windows CE supports only a TCP/IP network stack. Because IP addresses change in a mobile environment, MSMQ depends heavily on the following:

  • The ability to resolve a name to an IP address—Domain Name Service (DNS) or Windows Internet Naming Service (WINS).
  • The ability to resolve an IP address to a name—DNS reverse lookup or netbios node status.
  • To support roaming, Windows CE MSMQ routes messages internally by computer names, rather than IP addresses. This means that every device on a peer-to-peer configuration must have a unique name.

    A network registration daemon (NETREGD) provides name registration services for Windows CE devices. It ensures that the device name and IP address are registered with WINS when the device goes online. The daemon can also use the network tracking capability of Windows CE to register the device name when the network interface becomes available.

    Configuration and Administration Support

    Because the Windows CE independent client is designed to operate without support from a desktop-based domain, the standard MSMQ desktop administration and configuration tools, such as MSMQ Explorer, are not supported on Windows CE.

    All relevant administration information is stored on the Windows CE device, in the registry and in the base directory. You can configure MSMQ by setting the registry values directly, or by using the MSMQAdm utility, provided in the Windows CE SDK. Tasks administered through MSMQAdm include:

    • Browsing local queues
    • Purging messages
    • Deleting individual messages
    • Stopping and starting MSMQ service

      MSMQAdm includes scripting support, allowing you to automate routine tasks.

      Logging

      MSMQ on Window CE version 3.0 supports logging. When MSMQ is started and stopped, or a fatal error— as a corrupt file or a request for connection from an unidentified computer— encountered, it generates an entry in the MQLOGFILE text file in the MSMQ storage directory.

      Installable File Systems

      The base directory contains local and outgoing queues and message data, and MSMQ internal queues. One file is contained in each queue. At startup, MSMQ creates a machine journal queue and a dead letter queue if they are not already present.

      The Windows CE MSMQ service can use an installable file system for its base directory. Note, however, that the transactional nature of the native, RAM-based file system in Windows CE provides additional security for messages. If you move your queue to a non-transactional file system you must ensure that the file system is available when the message-queuing service is started. You can move the MSMQ storage from one file system or from one directory to another by stopping MSMQ, changing the base directory ( BaseDir) value in registry, and copying the contents of the storage to the new location.

      Note   MSMQ is a very storage-intensive application, so a slow file system may degrade the performance of a message queuing application significantly.

      Notes on Flash Card usage

      MSMQ can have its storage located on a Flash card, or Compact Flash card, just as it can on any other installable file system. This ensures that messages are not lost if the system suffers total power loss, or locks up so that it requires a hard reset. Keep in mind, however, that flash cards also use a simple FAT file system, which is neither transactional nor fault-tolerant. As with any installable file system, the flash card should not be removed from the system when MSMQ is operational—doing so may lead to message loss and file corruption. The user must always stop MSMQ before removing the flash card.

      MSMQ Implementation Scenarios

      • Store and forward messaging.When the sending and receiving applications run at different times, or one runs continuously while another runs only intermittently, the sender can store unsent messages on the device until the receiver is running and the two are connected. Alternatively, the sender can connect to another device that will receive the messages into its own queue, and then forward them when it establishes a connection with the receiver. For example, store-based retail sales applications can accumulate sales and inventory data and forward the information automatically to warehouse distribution centers and suppliers periodically during the day, and to regional sales offices at night Sales representatives working in the field can take orders on a mobile device, connecting to a server only to transfer the orders to a server application that tracks inventory and processes the orders, and to receive inventory status updates and confirmation of orders shipped
      • Connectionless communication.Whenever connections between senders and specific receivers are impractical. Messages can be routed through a server, or forwarded to another independent client that has a connection to the recipient.
      • Once and in-order messaging.When the cost of lost or duplicated messages is too great, the MSMQ transactional delivery mode and journaling capability assure that messages are delivered once, and only once, in the order they were sent. If a computer or the network fails, MSMQ will recover all messages automatically, preventing any message loss. For example, an automated assembly line might have a number of embedded Windows CE systems that would request delivery of installable items. Parts that arrived out of order, or that were delivered multiple times, could force the system to shut down.
      • Asynchronous and concurrent communication. When the sending application needs to perform other tasks and can't block while waiting for a response, message queuing allows the flow of activity to continue without interruption. For example, a physician using a portable Windows CE-based device to chart patient information could, during the course of an examination, request information on drug interactions from a central database, submit a list of symptoms as keywords for a Medline research query, receive results of diagnostic tests, and update insurance information—with all of this activity taking place in the background, allowing the physician to continue entering new information on the chart as it is obtained during the examination.
      • Journaling.When requests must be logged, audited, or possibly re-processed to recover from failures, MSMQ can journal copies of each message automatically. For example, a financial services application that transferred information from ATMs and other remote locations to a central processing center would use journaling not only to restore messages in the event of a system failure, but also to create an audit trail of activity.

        For More Information

        For detailed information on developing distributed applications that use the MSMQ Service, see the Microsoft Platform SDK documentation. For information specific to developing applications on Windows CE-based platforms, see the SDK documentation for your target platform.

        The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

        This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

        Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

        Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

        © 2000 Microsoft Corporation. All rights reserved.

        Microsoft, Win32, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

        The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

        
        

        ---

        © 2004 Microsoft Corporation. All rights reserved.