Message Pump as a Service – Routing Service

Since WCF 3.0 many developers (including Sasha and myself) needed to implement a message pump (or message router) which basically takes messages from an input channel and puts them on an output channel. This is useful for various scenarios which include:

• Basic Message Routing
• Protocol Bridging
• Service Aggregation
• Versioning

WCF 4.0 now ships with a Routing Service which fully supports message routing, thus decoupling the client from the server. This service supports:

• Basic message routing based on a configured filter table.
• Protocol bridging including transport conversion, SOAP version conversion etc.
• Security decoupling and impersonation.
• Error handling – configure alternate service endpoints in case of failure.
• Transactions – flow transactions and control of transactional queue reads (as opposed to the destructive reads done in WCF 3.0 and 3.5 which delete the message when it is read).

Service Discovery

Discovery is the ability to publish a service’s endpoint metadata and discover services using well defined criteria. This is very useful both during design time to find available service and during runtime to allow reduced configurations, location agility and dynamic/self-healing applications. This service is an implementation of WS-Discovery and is standard interoperable.

Discovery comes in a couple of modes:

• Ad-hoc Discovery – No central discovery server, and discovery is performed via multicast messages.
• Managed Discovery – A discovery proxy is used to facilitate discovery. This suppresses the use for multicasting, and it also allows us to expose our own service repository to all clients in a standard way.

WCF 4.0 provides a full implementation for the ad-hoc mode and all of tools and contracts for building your own custom managed discovery mechanism. “DiscoveryProxy” is the base class required for creating a discovery service.

Making a service discoverable is very simple – just add a “ServiceDescoveryBehavior” and a discovery endpoint (such as “UdpDiscoveryEndpoint”) and you’re good to go. On the client side all you have to do is use a “DynamicEndpoint” instance, use it to create an instance of your service and you’re done!

Adding announcements to services is just an easy – all you have to do is add an announcement endpoint and that’s it. This gives you a very impressive ability for the client to respond to service availability on the network.

These are the two main features in WCF 4.0 I'm super excited about. Back in the day (last year) I had to hand build my routing service myself, and anybody who did what I did knows how much of a pain it can be.

Then adding a discovery service on top of your routing service can make for a pretty mean and lean pub/sub system.

Excited to try out these new features...

Introducing Google Public DNS

12/03/2009 08:35:00 AM

When you type www.wikipedia.org into your browser's address bar, you expect nothing less than to be taken to Wikipedia. Chances are you're not giving much thought to the work being done in the background by the Domain Name System, or DNS.

Today, as part of our ongoing effort to make the web faster, we're launching our own public DNS resolver called Google Public DNS, and we invite you to try it out.

Most of us aren't familiar with DNS because it's often handled automatically by our Internet Service Provider (ISP), but it provides an essential function for the web. You could think of it as the switchboard of the Internet, converting easy-to-remember domain names — e.g., www.google.com — into the unique Internet Protocol (IP) numbers — e.g., 74.125.45.100 — that computers use to communicate with one another.

The average Internet user ends up performing hundreds of DNS lookups each day, and some complex pages require multiple DNS lookups before they start loading. This can slow down the browsing experience. Our research has shown that speed matters to Internet users, so over the past several months our engineers have been working to make improvements to our public DNS resolver to make users' web-surfing experiences faster, safer and more reliable. You can read about the specific technical improvements we've made in our product documentation and get installation instructions from our product website.

If you're web-savvy and comfortable with changing your network settings, check out the Google Code Blog for detailed instructions and more information on how to set up Google Public DNS on your computer or router.

As people begin to use Google Public DNS, we plan to share what we learn with the broader web community and other DNS providers, to improve the browsing experience for Internet users globally. The goal of Google Public DNS is to benefit users worldwide while also helping the tens of thousands of DNS resolvers improve their services, ultimately making the web faster for everyone.

Google now owns your 404 page. Can Somebody say $$$$