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 ...