Hello Cloud – Exploring .NET Service Bus
After submitting request before few weeks to allow me an access to the Windows Azure Services, Microsoft sends me an email with all necessary details on how to explore this new platform for developers. First thoughts on Azure were that this is another great marketing move from Microsoft, as attempt to answer on Amazon EC2, Rackspace's Mosso and Google services, but after few minutes playing around with examples in the cloud I’ve change my mind. This is definitely the most important challenge for every .NET developer because now the Cloud is something tangible.
Windows Azure is an upcoming operating system for the cloud from Microsoft which provides developers with on-demand compute and storage to host, scale and manage Web applications on the Internet through Microsoft data centers. Azure goes beyond what other providers. Using the Windows Azure tools, developers can build, debug, and deploy to Windows Azure directly from their existing development environment
In this article I’ll take a short overview on some very interesting features related to this platform - .NET Services.
Introduction to .NET Services
Microsoft .NET Services is a set of Microsoft-built and hosted cloud infrastructure services for building Internet-enabled applications constituted on Internet Service Bus that provides applications with a common infrastructure to name, discover, expose, secure and orchestrate Web Services as WCF. The following are the three broad areas.
.NET Service Bus
The .NET Service Bus provides a hosted, secure, and broadly accessible infrastructure for pervasive communication, large-scale event distribution, naming, and service publishing. Services can be exposed through the Service Bus Relay, providing connectivity options for service endpoints that would otherwise be difficult or impossible to reach. Endpoints can be located behind network address translation (NAT) boundaries, or bound to frequently changing, dynamically assigned IP addresses, or both.
.NET Access Control Service
The .NET Access Control Service is a hosted, secure, standards-based infrastructure for multiparty, federated authentication and rules-driven, claims-based authorization. The Access Control Service's capabilities range from simple, one-step, user name/password-based authentication and authorization with Web-style HTTP requests to sophisticated WS-Federation scenarios that employ two or more collaborating WS-Trust Security Token Services. The Access Control Service allows applications to rely on .NET Services solution credentials for simple scenarios or on on-premise enterprise accounts managed in Microsoft Active Directory and federated with the Access Control Service via next-generation Microsoft Active Directory Federation Services.
.NET Workflow Service
The .NET Workflow Service provide a hosted environment for service orchestration based on the familiar Windows Workflow Foundation development experience. The Workflow services will provide a set of specialized activities for rules-based control flow, service invocation, as well as message processing and correlation that can be executed on demand, on schedule, and at scale inside the .NET Services environment.
Service Bus – Beginning of Cloud Story
The most important part of the Azure is actually the Service Bus represented as a WCF architecture. Key capabilities of the Service Bus are:
- A federated namespace model that provides a shared, hierarchical namespace into which services can be mapped. This allows providing any endpoint with a stable, Internet-accessible URI, regardless of location.
- A service registry service that provides an opt-in model for publishing service endpoints into a lightweight, hierarchical, RSS-based discovery mechanism.
- A lightweight and scalable publish/subscribe event bus.
- A relay and connectivity service with advanced NAT traversal and pull-mode message delivery capabilities acting as a "perimeter network (also known as DMZ, demilitarized zone, and screened subnet) in the sky" for services that would otherwise be unreachable due to NAT/Firewall restrictions or frequently changing dynamic IP addresses, or that do not allow any incoming connections due to other technical limitations.
So how it works?
Let’s think on Service Bus as a Highway where our Client request drives. On the highway there is a traffic (Consumer Requests) and a lot of exit roads which leads to our service.
First, each solution is expressed as simple URI identifier – root of hierarchical namespaces, represented as sb://servicebus.windows.net/services/[Solution] and followed with details on the certain solution and/or some specific details. For example, the complete Namespace for Hello Cloud Example could be:
sb://servicebus.windows.net/services/softlab/HelloCloud/v1
where softlab is the solution registered at the Service Bus.
So you suppose that the consumers on our service must use the same namespace that we have defined at our host and you are right. The client needs to reference an Endpoint Address in the Cloud (in this case Azure Service Bus) providing needed service namespace as address and using already defined contract at our host – the same WCF Service Contracts structure as we already knows. He sends his request on the Service Bus and the provided Namespace which actually represents a ticket to the exit road directs to the service host.
With other words, the Service Bus acts as a Web Service intermediary router. It is completely transparent for SOAP messages and protocols used between endpoints which can use message-level security (with or without reliance on the Access Control Service) to protect messages and therefore make it effectively impossible for the Service Bus to inspect or modify elements in the message if that were a concern. Also, Endpoints can also use other WS-* protocols, such as WS-ReliableMessaging or WS-Coordination/WS-AtomicTransaction or any other custom Web Services protocol transparently through the Relay.
So where is our service hosted?
Service Endpoints are exposed directly from our machines/servers registered with unique Namespace on the Service Bus. This is ideal scenario for machines with constrained Internet connectivity where:
- The host machine resides behind a Network Address Translation (NAT) service in which its primary IP (v4) address is in a private range that is not Internet-addressable (i.e. 10.x.x.x, 192.168.x.x).
- The host machine resides behind one or multiple firewalls that prevent incoming connections.
- The host machine or its Internet gateway does not have a static (permanently assigned) IP address with a publicly registered domain name.
All of these constraints apply to the vast majority of machines in corporate, small business and home networking environments. For many software vendors, these constraints represent a major obstacle for writing more powerful, network-aware applications that leverage Internet connectivity for the benefit of their customers, for example, for proving direct business-to-business connectivity that even small businesses can participate in.
Because we are talking for WCF Services all the time, the .NET programming model for the Service Bus provides specific bindings. Those bindings creates publicly reachable, and if desired, publicly discoverable HTTP listener endpoints on the Service Bus:
- BasicHttpRelayBinding: Uses HTTP as the relay transport.
- NetTcpRelayBinding: Uses TCP as the relay transport.
- NetOnewayRelayBinding: Supports only one-way messages.
- NetEventRelayBinding: Supports one-way multicast eventing and allows N event publishers and M event consumers to rendezvous at the same endpoint.
- WebHttpRelayBinding: Supports plain HTTP messages with support for XML and Raw (binary) message encodings.
- WS2007HttpRelayBinding: Supports SOAP 1.2 messaging with the latest OASIS standards for Reliable Message Exchange and Security.
- WSHttpRelayBinding: Supports SOAP 1.2 messaging with the draft WS-* standards for Reliable Message Exchange and Security that are available in Windows Communication Foundation (WCF) 3.0.
And final question asked from the developer/business perspective is how to discover that service?
Each Solution has an ATOM 1.0 Feed for all discoverable end points, simply browse to the predefined page provided for the solution registered at the Service Bus, the same one provided in the Namespace before. For example, if you browse on .NET Service Bus Solution you should find all public available services:
If you like to try Windows Azure, just take few minutes and browse at the Azure Platform Developer Services web page. You can register for access on Windows Azure, SQL Data Services, .NET Services or Live Services; download CTP SDK’s and learn many thing about them.