MSMQ over HTTP is a push-only technology
If you are designing a system that uses MSMQ over HTTP then you need to take into account that you can only push messages around the system and not pull them. So you can send from Machine A to Machine B but you can't do a similar remote receive from B to A.
The reason for this is that remote receives always use the RPC protocol even if you are specifying DIRECT=HTTP or DIRECT=HTTPS. The functionality used to be present in Windows XP before service pack 2 but was withdrawn because of the limitations that using RPC imposes:
- Sending over HTTP uses just port 80 but receiving over RPC requires extra ports (135, 2103, 2105) to be opened in firewalls, which isn't going to be inituitive unless you know how remote receives work under the covers.
- Sending over HTTPS will ensure the messages are encrypted/authenticated but receiving over RPC means the data will be in clear text on the wire which would be an unacceptable security breach.
Note - Between Windows 2003 servers (and above), the RPC traffic is encrypted.
Comments
Anonymous
March 24, 2009
John, another scenario that maybe you can help me with. Would I be able to receive messages from the server (machine B) from machine A? Machine A is on a dynamic IP somewhere (can send messages over HTTP just fine to B). B is behind the firewall and I'm using a mapping file like you listed in your other blog for redirection from the public IP to the internal IP of B. So can B send messages to a queue on itself and can A check if there are messages on that queue and if so retrieve them? thanks. -MarkAnonymous
March 24, 2009
Hi Mark, That scenario is exactly as described in the blog post above. As it says: "MSMQ over HTTP is a push-only technology". You would have to open up the firewall to all the required RPC ports and perform traditional message retrieval. If you want to use MSMQ over HTTP, machine B will need to send messages to machine A. Cheers John BreakwellAnonymous
March 24, 2009
Hmm... so it looks like I'll need another technology to accomplish this, maybe WCF. the main issue/problem is the client, A will be dynamic and possibly behind a firewall/router. thanks for the help. -MarkAnonymous
September 24, 2010
Look at ActiveMQ. It has can use the REST API and work on port 80 via simple get and post. or secure https as well.