Service Bus Event Bus
If your applications are already built on the .NET Framework and your services are built using the Windows Communication Foundation (WCF), it is often just a matter of changing your application’s configuration settings to have your services listen on the Relay instead on the local machine.
The Microsoft.ServiceBus client framework provides a set of WCF bindings that are very closely aligned with the WCF bindings available in the .NET Framework version 3.5. The key difference between the standards WCF bindings and their Relay counterparts is that they establish a listener in the cloud, instead of listening locally. To use these bindings, specify the appropriate “relay” binding (that provides the connectivity and messaging semantics you’re after) and a relay address when defining the WCF endpoint. Then when you open the ServiceHost (for a receiver) or a ChannelFactory (for a client), the WCF infrastructure takes care of communicating with the relay behind the scenes. Despite this WCF integration, the .NET Service Bus is based on open Internet standards. This allows the service bus to connect applications across a variety of platforms and dramatically increased scale-out potential.
The following table describes the mapping between WCF bindings and the Service Bus bindings:
|Standard WCF Binding||Eqivalent Relay Binding||Description|
Uses HTTP as the relay transport.
Supports plain HTTP messages with support for XML and Raw (binary) message encodings.
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.
Supports SOAP 1.2 messaging with the latest OASIS standards for Reliable Message Exchange and Security.
Provides a context-enabled binding for the WsHttpRelayBinding.
Uses TCP as the relay transport.
Supports only one-way messages.
Supports one-way multicast eventing and allows N event publishers and M event consumers to rendezvous at the same endpoint.
Like its WCF precedessor, the Service Bus uses event bindings to link services with URIs, and can use many of the same types of bindings. The one main difference is the NetEventRelayBinding, which does not have an exact counterpart in the standard bindings. This binding provides access to the multicast eventing capability in the Service Bus. Using this binding, clients act as event publishers and listeners act as subscribers. An event-topic is represented by an agreed-upon name in the naming system. There can be any number of publishers, and any number of subscribers that use the respective named rendezvous point in the Relay. Listeners can subscribe independent of whether a publisher currently maintains an open connection, and publishers can publish messages regardless of how many listeners are currently active—including zero. The result is a very easy to use, lightweight, one-way rendezvous event distribution mechanism that does not require any particular setup or management.
All WS-Security and WS-ReliableMessaging scenarios that are supported by the standard bindings are fully supported through the Relay. Transport-level message protection using HTTPS or SSL-protected TCP connections is supported as well.
If you prefer RESTful services over SOAP services, you can build them on the WebHttpRelayBinding using the WCF Web programming model introduced in the .NET Framework 3.5.
The Relay knows how to route SOAP 1.1, SOAP 1.2 messages, and HTTP requests transparently.
Did you find this information useful? Please send your suggestions and comments about the documentation.