Share via

Store and forward servers

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Store and forward servers

When messages are sent over HTTP transport, the network names of the computers within an organization and the names of the queues hosted on them do not need to be disclosed to message senders. Message Queuing 3.0 can map external and internal names, protecting internal resources, and providing a solution for messaging through firewalls. Mapping is enabled on a store and forward server, positioned in the front-end of the enterprise, where all incoming HTTP requests are directed. If messages meet mapping criteria, they are forwarded further into the enterprise. For instance, only messages arriving by means of an HTTPS session, or messages whose sender can be authenticated, or messages selected by another security criterion will be forwarded. This ensures that only authorized messages are ever presented to corporate servers.

Logical and physical addresses

Using this mapping facility, HTTP messages can be redirected from a logical address, accessible from the Internet, to a corresponding internal physical address. These are defined as follows:

  • Logical address. Contained in URL format in the <to> subelement of the <path> element of the SRMP Message.

  • Physical address can be any of the following:

    • A queue on the target computer specified in the logical address, to which the message must be written by the Message Queuing service.

    • A queue on a computer in the internal network. To deliver the message, an HTTP/HTTPS request call is made by the Message Queuing service handling the message.

Mappings are created manually by including <Redirections> entries in XML mapping files. Each <Redirections> element contains 0 or more <redirection> elements, each of which contains exactly one <from> subelement and exactly one <to> subelement. Each <redirection> element describes a map from a logical address (<from>), to a physical address (<to>). These XML mapping files must be stored in the \Windows\System32\Msmq\Mapping folder. A sample mapping template is provided in this folder.

The following example illustrates an XML mapping file:

<Redirections>
    <redirection>
      <from>https://www.fabrikam.com/accounts</from>
      <to>https://Accounts01/msmq/private$/DestQ</to>
    </redirection>
  </Redirections>

When an SRMP message reaches the computer specified as the logical address, the Message Queuing service uses a local resolution algorithm to map the logical address to the physical address.

Local resolution algorithm

A local resolution algorithm defines how the local Message Queuing service on the target computer specified in the logical address resolves the logical address into its physical address.

Transparent mapping

By default, if a message arriving from a remote computer address cannot be matched with a physical address in the mapping file, the message is discarded. However, if transparent mapping is enabled, a physical address for the message is set to the message's logical address. To enable transparent mapping, create the MQS_TransparentSFD registry value as indicated in the Outbound message redirection section of this topic.

The local resolution algorithm works as follows:

  • If the logical address specifies a public or private queue on the local computer, and the queue exists, the physical address is set to the logical address of the queue.

  • Otherwise, the Message Queuing service searches through all the <redirection> elements in its local mapping files to try to match the logical address with a <from> subelement in one of the local mapping files, but the corresponding <to> subelement does not indicate a local public or private queue, it sets the physical address to match this <to> subelement, and forwards the message to the remote computer specified in this <to> subelement. This process is called redirection.

  • If transparent mapping is enabled, and the logical address of a message arriving from a remote computer cannot be resolved by any of the above methods, the physical address of the message is set to its logical address and the message is stored on the local computer.

  • If transparent mapping is not enabled, and the logical address of a message arriving from a remote computer cannot be resolved by any of the above methods, the message is discarded.

  • If the logical address of a message arriving from a local application cannot be resolved by any of the above methods, the physical address will be set to the logical address.

Hence if in the example above https://Accounts01/msmq/private$/DestQ does not point to a local private queue, then any SRMP message that is sent to the logical address specified will be forwarded to the computer Accounts01, where it will be written into the local private queue DestQ if such a local queue exists (subject to the normal authorization process) or it will be discarded silently if such a queue does not exist. If this <redirection> element is present in a mapping file on some other computer, the physical address of the message will be set to https://Accounts01/msmq/private$/DestQ and the message will be forwarded to this URL.

This provides a means to put HTTP messages sent to a logical address into an interim queue on the store and forward server in the receiving side of a perimeter network. From here they can be directed to the corresponding queue on a computer in the internal network.

Using wildcards

Limited use of regular expressions in <from> elements are supported. Asterisk-terminated URLs can define a redirection from multiple logical addresses to a single physical address. Only this type regular expression can be used, and only in the <from> element:

<Redirections>
  <redirection>
    <from>https://www.fabrikam.*</from>
    <to>https://Accounts01/msmq/private$/DestQ</to>
  </redirection>
</Redirections>

In this example, any message with a logical address that starts with the string https://www.fabrikam. will be redirected to the physical address in the <to> element. Thus, for example, messages with logical addresses https://www.fabrikam.com/accounts and https://www.fabrikam.net/data will be both redirected to the physical address https://Accounts01/msmq/private$/DestQ.

This functionality is based on software provided by J. Kanza. For copyright information for this software, see Message Queuing: External software copyright and permission notice.

Order acknowledgment messages for transactional HTTP messages

Transactional messages are to be delivered exactly once and in the order in which they are sent. When transactional messages (streamed HTTP messages) are sent over HTTP from the internal network of an enterprise to the Internet, the physical address of the sender's order queue must be translated into a logical address using a mapping, to direct the order acknowledgment messages (stream receipts) from the receiving computer (outside the sender's enterprise), back to the sender's order queue.

Mappings between logical addresses for sending streamed HTTP messages from local applications and logical addresses for returning order acknowledgment messages (stream receipts) from the recipient computers are created manually by including <StreamReceiptSetup> entries in an XML mapping file that is stored on the local computer. Each <StreamReceiptSetup> entry contains 0 or more <setup> elements, each of which contains exactly one <LogicalAddress> subelement and exactly one <StreamReceiptURL> subelement. In each <setup> entry, the <StreamReceiptURL> element specifies the URL that will be included in streamed (transactional) HTTP messages sent from a local application to a logical address matching the URL specified in the <LogicalAddress> element.

When a streamed HTTP message is sent from a local application, the local Message Queuing service searches the <setup> entries in the mapping file. If a URL matching the logical address of the message is found in the <LogicalAddress> element of one of the <setup> entries, the URL specified in the accompanying <StreamReceiptURL> element is inserted into the <sendReceiptsTo> element of the <Stream> entry in the SOAP envelope of the message.

Each <setup> element also defines an implicit mapping that redirects every HTTP message arriving at the local computer with the destination specified in <StreamReceiptURL> to the physical address of the local order queue. Such messages are normally stream receipts (order acknowledgment messages).

A <StreamReceiptSetup> entry may contain one <default> element, which defines the default stream receipt URL that the local Message Queuing service inserts into every outgoing streamed (transactional) HTTP message, unless the logical address of the message matches the <LogicalAddress> element in one of the <setup> elements.

The following is an example of an XML mapping file that specifies the correspondence between a logical address for sending streamed HTTP messages from local applications and the logical address for returning stream receipts from the recipient computer along with the default URL for returning stream receipts:

<StreamReceiptSetup xmlns="msmq-streamreceipt-mapping.xml">
  <setup>
    <LogicalAddress>
      https://https://www.fabrikam.com/accounts
    </LogicalAddress>
    <StreamReceiptURL>
      https://www.fabrikam.com/StreamReceipts
    </StreamReceiptURL>
  </setup>
  <default>
    https://Accounts01/msmq/PRIVATE$/order_queue$
  </default>
</StreamReceiptSetup>

The limited use of regular expressions in the context of <LogicalAddress> elements is supported. Asterisk-terminated URLs can define the correspondence of multiple logical addresses to a single stream receipt URL. This is the only type of regular expression supported in <StreamReceiptSetup> entries, and it is allowed only in the <LogicalAddress> element.

In following example, any message with a logical address that starts with the string https://www.fabrikam.com/\* will use the stream receipt URL specified in the <StreamReceiptURL> element.

<StreamReceiptSetup xmlns="msmq-streamreceipt-mapping.xml">
  <setup>
    <LogicalAddress>
      https://www.fabrikam.com/*
    </LogicalAddress>
    <StreamReceiptURL>
      https://www.fabrikam.com/StreamReceipts
    </StreamReceiptURL>
  </setup>
</StreamReceiptSetup>

Outbound message redirection

The number of HTTP/HTTPS sessions established and the number of client certificates needed can be minimized by routing all outbound messages (messages sent out of the enterprise) through a dedicated intermediate host. This dedicated intermediate host is called a transparent store and forward server (TSFD).

A computer with HTTP Support installed is configured as an intermediate host TSFD by creating the following REG_DWORD value in the registry and setting it to a value of 1:

HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\MachineCache\MQS_TransparentSFD

After setting the registry, restart the Message Queuing service for the changes to take effect. After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

Any other value or a lack of this registry key indicates that the computer will not function as a TSFD and that all messages sent to remote queues will be discarded if the computer does not have a regular XML mapping file for them.

For a source computer to be able to redirect its messages through an intermediate host, a special XML configuration file needs to be added. This configuration file defines which messages will be redirected through an intermediate host and which will not. This XML configuration file must be stored in the \Windows\System32\Msmq\Mapping folder and is loaded when the Message Queuing service starts.

The following is an example of an XML configuration file that specifies the correspondence between the address of a destination queue and an intermediate host:

<outbound_redirections xmlns="msmq_outbound_mapping.xml">
  <redirection>
    <destination>https://target_host/msmq/private$/DestQ</destination> 
    <through>https://intermediate_host/msmq</through> 
  </redirection>
</outbound_redirections>

The <outbound_redirections> element contains 0 or more <redirection> subelements, each of which in turn contains exactly one <destination> subelement and exactly one <through> subelement. Each <redirection> element describes a redirection (or mapping) of the physical address of the destination queue given in the <destination> subelement to the virtual directory on the intermediate host given in the <through> subelement.

MSMQ 3.0 supports a limited use of regular expressions in a <destination> element. Users can use an asterisk-terminated URL to define a redirection of multiple physical addresses of destination queues to a single address of a virtual directory on an intermediate host.

In the following example, all messages sent using the HTTP protocol will be redirected through the intermediate host:

<redirection>
  <destination>https://*</destination> 
  <through>https://intermediate_host/msmq</through> 
</redirection>

Each <outbound_redirections> element may contain 0 or more <exception> subelements. You can use <exception> elements to exclude messages sent to specific queues from being redirected by outbound <redirection> rules.

MSMQ 3.0 supports a limited use of regular expressions in an <exception> element with the same restrictions as for the previously described <destination> element.

In the following example, all messages sent to private queues on special_host will not be redirected through the intermediate host:

<exception>https://special_host/msmq/private$/*</exception>

You can use the keyword local_names in an <exception> element to exclude messages sent to any internal (intranet) host from being redirected by outbound <redirection> rules.

In the following example, no messages sent to internal hosts will be redirected through the intermediate host:

<exception>local_names</exception> 
</outbound_redirections>