The MSMQ binding is designed to be employed in the intranet. It cannot go through
firewalls by default, and more importantly, it uses a Microsoft-specific encoding and
message format. Even if you could tunnel through the firewall, you would need the other
party to use WCF as well. While requiring WCF at both ends is a reasonable assumption in the
intranet, it is unrealistic to demand that from Internet-facing clients and services, and it
violates the core service-oriented principles that service boundaries should be explicit and
that the implementation technology used by a service should be immaterial to its clients.
That said, Internet services may benefit from queued calls just like intranet clients and
services, and yet the lack of an industry standard for such queued interoperability (and the
lack of support in WCF) prevents such interaction. The solution to that problem is a
technique I call the HTTP bridge. Unlike most of my other techniques
shown in this book, the HTTP bridge is a configuration pattern rather than a set of helper
classes. The HTTP bridge, as its name implies, is designed to provide queued calls support
for clients and services connected over the Internet. The bridge requires the use of the
WSHttpBinding (rather than the basic binding) because it is a transactional binding. There are two parts to the HTTP bridge. The bridge enables WCF clients to queue up calls to an Internet service that uses the WS binding, and it enables a WCF service that ...