.NET Services and The Service Bus

The Service Bus is a new messaging infrastructure part of the new Windows Azure Services. It addresses a few Connectivity challenges we all are aware of:

• IPv4 Address Shortage
  • Dynamic IP address allocation
  • Network address translation

• Firewalls layered over firewalls over firewalls

So how does the service bus address these problems? There are a couple of components the service bus consist of:

- Naming: Because of the practical constraints of DNS (High update propagation latency, DNS names hosts and not instances etc.) the service bus naming system works in a different way i'm not going to dive into it now, but a few features are: R/W access with Access Control through the Service Bus Registry, Updates are reflected instantaneously and it names endpoints, not machines.

- Service Registry: The service registry is registry for service endpoints, not a general purpose directory. The registry is layered over the naming system and the services should publish themselves in the registry. The registry also provides the family of bindings for the service bus. Right now the service bus can be used with the following bindings:

• BasicHttpBinding
• WebHttp
• WSHttp
• WS2007Http
• WSHttpContext
• WS2007Httpfederationg
• NetTcp
• NetTcpContextBinding

So how does the service bus works with these bindings? If you use NetOnewayRelaybinding then the Receiver creates an outbound connect bidirectional socket and register in the cloud (Registry of the Service Bus) (TCP/SSL 828 outbound open required) The sender outbound connect one-way net.tcp (tcp/ssl 808/828) to the Service Bus. The sender sends a message the Service Bus creates a route to the receiver.

The NetEventRelayBinding allows muliple receivers, so you can send a message and both/more receivers will receive the message.

NetTcpRelayBinding / Relayed is the one you should almost always use, because it got the highest throughput. A connection starts just like NetOneWay, but instead of connecting to the Service Bus we connect to the load-balanced front-end nodes. These nodes are some sort of Socket-Socket Forwarders the nodes sends a control message to the cloud and the cloud sends a control message to the receiver. The receiver then connects to the socket-socket forwarder and then the receiver and sender are connected through the socket-socket-forwarder.

The last part I haven't discussed is security, this is where the Relay Access Control Model comes in.

- Relay Access Control Model:

RECEIVER MODEL: The receiver goes to the acces control service (azure) and acquire access token and asked for a claim for listen permissions on the service bus relay. Then this access token with subscription is passed to the service bus relay. The service bus relay will evaluate that token.

SENDER MODEL: The same way: get a token send it to the relay, relay evaluate, and now the relay will pass the normal message to the receiver.

There's even a possibility for you if you don't want to use the Access Control Service just add the following line in your BindingConfig <security relayClientAuthenticationType="None"/>. I don't think it's a good idea, but you can.