Boundaryless WCF and REST service communication -- The Windows Azure platform AppFabric Service Bus (with Access Control!)

This past month I've been doing some work on the AppFabric Service Bus. It's hard to get a grip on the "feature" associated with this technology at first glance, but I'll take my first shot right here: "The Windows Azure platform Service Bus enables you to build Web services and clients that can traverse boundaries like firewalls and NAT routers without making any direct modifications to those boundaries themselves. What does this give you? Nothing short of the ability to glue applications together and stretch them around the world --anywhere the data or applications reside, or to any platforms (smart phones, anyone? Dishwashers? Toasters?) on which the callers reside. In short, it is the glue that makes secure Software plus Services not only a reality, but a reality that you can begin building today."

OK, that's a little overheated (geez: "a reality that you can begin building today?" ouch!! :-), but technically it is very close to what's going on here. You must realize that a production-quality scenario involves a lot of additional work -- but the genius-cool of this bit of tech is that you do NOT have to build the secure glue system between data chunks and applications -- just build your WCF service that exposes the data or application behavior, and instead of configuring it for local behavior, you configure it to use one of the relay bindings that come with the Service Bus, and to use tokens from the Access Service to authenticate and authorize when communicating with the Service Bus.

Somewhere in the cloud waits the Service Bus (and Access Control service). When you start your local WCF service, the configured relay bindings will communicate with the Service Bus in the cloud (if permission is granted), and then analyze the network between the two endpoints, establishing a bidirectional stream through any firewalls and NAT systems. Clients anywhere, on any Web-enabled platform, can then (if they have permission from the Access Control service), connect to the Service Bus as though it is the original service. The endpoint addresses that the client use -- Service Bus namespaces and names -- are protocol and location independent. Although you can secure the endpoint address information, the name itself has meaning only to the Service Bus -- and to nothing else.

 What kind of tokens can you use to be authenticated and authorized? The easiest way is to use Simple Web Tokens, for which the Access Control service is a trusted provider to the Service Bus. Because the Access Control service is extensible, however, you can build a security system that uses the Access Control service to authenticate and authorize Service Bus access without changing the original WCF service or the Service Bus configuration at all. (And, as the Access Control service supports AD FS integration -- SAML tokens -- you can do very robust and integrated security.)

The ability to communicate across firewall and NAT boundaries without management involvement AND the ability to do this securely across platforms -- both of these features are needed to make it possible for you to build the cloud/desktop/server/gadget applications that you can envision for your customers ease and your productivity. This is simply way, way cool.

 I'll do some examples very soon.