Udostępnij za pośrednictwem

MSMQ over HTTP

  • Artykuł

Why?

Generally when using MSMQ within your organization or within your network it's quite common use the default native transport (TCP over port 1801).  When going across various network or between multiple organizations, one may not always have control over routers, firewalls, or other devices which could block 1801, and in many cases it's just not a good idea to open additional ports.

MSMQ v3.0 (XP and 2003) and later have the ability to send messages over HTTP, in short the MSMQ message is sent over port 80 (or 443 for SSL).  The message is picked up on the receiving end (via IIS) and directed to the appropriate queue.

 What Needs to be Installed?

In order to only send messages, no additional components for MSMQ need to be installed except for "Common".  To receive MSMQ messages over HTTP though, the MSMQ/HTTP option must be selected.  This installs and configures the required MSMQ components in IIS, and should allow messages to be received.

Keep in mind that when sending transactional messages, that you are both sending and receiving ... the original message gets sent, and the acknowledgement is then returned.  So in the case of transactional messages, you will most likely want the MSMQ/HTTP component installed on both the sender and receiver.

How to Send Messages?

Sending messages over HTTP is simple, generally no coding changes are required except to specify a format name using HTTP/HTTPS.  An format name for an MSMQ over HTTP message may look something like DIRECT=https://www.mydestination.com/msmq/myQueueName.

There is also the ability to use virtual queues, which then map to a real queue, so the real queue name doesn't have to be exposed.   This is done through the config files located in the %windir%\system32\msmq\Mapping directory.  Information on modifying these files is contained in the Word documents linked through the Resources section below.

What about Acknowledgements?

Regular MSMQ acknowledgements are returned to the IP of the sender.  In the case of HTTP messaging this would be difficult as the message is often sent from inside a private network using an internal IP.   MSMQ over HTTP uses Stream Receipts to address this issue, in short a URL can be specified where the acknowledgements messages should be sent.  So long as the receiver can connect to the specified Stream Receipt URL, we should be able to return the acknowledgement messages successfully (also over HTTP).

The Stream Receipt configuration also allows transactional messages to be sent across an NLB or similar device, which is NOT the case with regular MSMQ.  In these scenarios, using MSMQ/HTTP may provide a significant advantage if transactional messages are required.

Security?

Security is a concern, and even if the data within the message body is encrypted, the queue name and other information relating to the message are still viewable in the HTTP packets (you should be able to see this with a simple network capture).  To address this, HTTPS can be used, or for additional security, client certificates.

It's easy to misplace the certificates when using the additional security featured.  The Trusted CA certificate needs to be placed in the Certificate store for the computer.  If using client certificates, then the certificates need to be placed in the store for the MSMQ service.

Downsides?

In a single word, performance.  MSMQ over HTTP is slower than regular MSMQ simply because of the overhead involved.  The message must first get sent to IIS then gets passed to MSMQ, instead of being sent natively.  In many cases where volume is not terribly high or high-performance is not a top requirement, MSMQ over HTTP(S) provides an excellent solution to transporting application data between multiple networks. 

Additional Resources:

The following documents are excellent resources on understanding how to get started with MSMQ/HTTP(S):

MSMQ HTTP Deployment Scenarios for Windows Server 2003 and Windows XP Professional

Configuring HTTPS Messaging for MSMQ 3.0

Comments