Delivering Messages Sent over the Internet

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

MSMQ 3.0 supports HTTP messaging through port 80 and HTTPS messaging through port 443. These ports must be opened on firewalls to permit HTTP and HTTPS traffic. Special configurations, which may compromise security, are not necessary for HTTP/HTTPS messaging.

However, many organizations connect to the Internet using a proxy server for dispatching outgoing messages and a perimeter network protected by firewalls for routing incoming messages. The proxy server creates a protected channel for passing messages from the private network to the Internet and provides caching. Message Queuing uses an HTTP proxy to connect to URL addresses for delivering HTTP messages. Message Queuing needs the name of the proxy server and the applicable port to which it should connect. At the same time, there may be a list of target names for which the proxy connection is bypassed; that is, URL addresses that do not need to be accessed through the proxy server. An attempt is made to establish a direct connection with such targets. All of the information regarding proxy servers is stored in registry entries.

You can use the Proxy Configuration utility to configure a proxy server. To configure a proxy server, type the following command at the command prompt:

proxycfg.exe -p ProxyServerName:PortNumber BypassedTargets  

The current proxy server configuration is read whenever an outgoing queue is created to send messages to a new URL. It is not necessary to stop and restart the Message Queuing service for new proxy settings to take affect. However, if you change the proxy server configuration using the Proxy Configuration utility and you want an active outgoing queue to use the new settings, you must pause and resume that outgoing queue. Outgoing queues can be paused and resumed programmatically using the MSMQOutgoingQueueManagement.Pause and MSMQOutgoingQueueManagement.Resume methods.

Message Redirection

When HTTP messages are sent over an intranet or over the Internet, the network names of the computers within an enterprise and the names of the queues hosted on them need not be disclosed to the senders. MSMQ 3.0 can redirect an HTTP message from the logical address contained in the <to> subelement of its <path> element to a corresponding physical address. The physical address may designate a queue that exists on the target computer specified in the logical address or a queue hosted on a computer in the internal network, to which an HTTP/HTTPS request call must be made by the Message Queuing service handling the message to deliver it.

Mappings specifying the correspondence between logical and physical addresses are created manually by including <Redirections> entries in XML mapping files. Each <Redirections> element contains 0 or more <redirection> subelements, each of which in turn contains exactly one <from> subelement and exactly one <to> subelement. Each <redirection> element describes a redirection (or mapping) of the logical address given in the <from> subelement to the physical address given in the <to> element.

These XML mapping files must be stored in the \Windows\System32\Msmq\Mapping folder.

The following is an example of an XML mapping file that specifies the correspondence between a logical address and the physical address of an application queue hosted on a computer within an enterprise:

<Redirections>  
  <redirection>  
    <from>http://www.northwindtraders.com/msmq/accounts</from>  
    <to>http://Accounts01/msmq/PRIVATE$/DestQ</to>  
  <redirection>  
</Redirections>  

MSMQ 3.0 supports a limited use of regular expressions in the content of the <from> elements. Users can use asterisk-terminated URLs to define a redirection from multiple logical addresses to a single physical address. This is the only type of regular expression supported in <redirection> entries, and it is allowed only in the <from> element.

The following example illustrates how to create a mapping file that specifies the correspondence between multiple logical addresses and a single physical address:

<Redirections>  
  <redirection>  
    <from>https://www.northwindtraders.com/*</from>  
    <to>http://Accounts01/msmq/PRIVATE$/DestQ</to>  
  </redirection>  
</Redirections>  

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

When an HTTP message reaches the computer indicated by the logical address specified in the message, the Message Queuing service on that computer searches through all the <redirection> elements in its local mapping files in an attempt to find the logical address in the <from> subelement of one of these elements. If the Message Queuing service finds a <redirection> element that contains a <from> subelement that matches the logical address, it sets the physical address to the content of this <to> subelement and forwards the message to the remote computer specified in the <to> subelement. This process is called redirection.

If the Message Queuing service does not find a <redirection> element that contains a <from> subelement that matches the logical address, and if the logical address of the message specifies a public or private queue that exists on the local computer, the physical address is set to the logical address.

If the <redirection> element in the preceding example is present in a local mapping file on the computer specified by the logical address http://www.northwindtraders.com/msmq/accounts, then any HTTP message that is sent to the logical address http://www.northwindtraders.com/msmq/accounts will be forwarded to the computer named 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.

Messages sent over HTTP/HTTPS to a logical address can be placed in an interim queue on a store-and-forward server (SFD) in the perimeter network on the receiving side, from which they can be directed to the corresponding queue hosted on a computer within the enterprise.

By default, if the logical address of a message arriving from a remote computer cannot be resolved in any of the ways described, the message is discarded. If the logical address of a message sent by a local application cannot be resolved in any other way, the physical address is set to its logical address.

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 internal name (physical address) of the sender's order queue is translated using a mapping into a logical address for sending the order acknowledgment messages (stream receipts) from the recipient computer (which is not located in the sender's enterprise) back to the sender's order queue.

Mappings specifying the correspondence 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> subelement 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> subelement.

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> subelement of one of the <setup> entries, the URL specified in the accompanying <StreamReceiptURL> subelement 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> subelement 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://http://www.northwindtraders.com/msmq/accounts  
    </LogicalAddress>  
    <StreamReceiptURL>  
      https://www.northwindtraders.com/msmq/virtual_order_queue  
    </StreamReceiptURL>  
  </setup>  
  <default>  
    http://Accounts01/msmq/virtual_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 the following example, any message with a logical address that starts with the string http://www.northwindtraders.com/\* will use the stream receipt URL specified in the <StreamReceiptURL> element.

<StreamReceiptSetup xmlns="msmq-streamreceipt-mapping.xml">  
  <setup>  
    <LogicalAddress>  
      http://www.northwindtraders.com/*  
    </LogicalAddress>  
    <StreamReceiptURL>  
      http://www.northwindtraders.com/msmq/virtual_order_queue  
    </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 adding and setting the following registry entry to 1:

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

Any other value or a lack of this registry entry 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>http://target_host/msmq/private$/DestQ</destination>   
    <through>http://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> subelement 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> subelement. 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>http://*</destination>   
  <through>http://intermediate_host/msmq</through>   
</redirection>  

Each <outbound_redirections> element may contain 0 or more <exception> subelements. You can use <exception> subelements 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> subelement with the same restrictions as for the <destination> subelement described earlier.

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

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

You can use the keyword local_names in an <exception> subelement 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>  

More Information