Programming WCF Services

HTTP Bridge

The MSMQ binding is designed to be employed on 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 though the firewall, you would need the other party to use WCF. While requiring WCF at both ends is a reasonable assumption on the intranet, it is unrealistic to demand that from Internet-facing clients and services, and it violates a core service-oriented principle that service boundaries are explicit and that the implementation technology used by the service is 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 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 in a small framework. The HTTP bridge, as its name implies, is designed to provide queued calls support when going over the Internet to a service or a client. The bridge requires the use of WSHttpBinding because it is a transactional binding. The bridge has two parts to it. The bridge enables WCF clients to queue up calls to an Internet service that uses the WS binding. The bridge also enables a WCF service that exposes an HTTP endpoint over WS binding ...