Service Bus Brokered VS Relayed Messaging

Question

I have a question that is confusing me what are the differences between the types of service bus, the brokered messaging and the relayed messaging? I am not looking for it from the development perspective but I want to understand more the concept and the differences between them.

Thank you.

Answer 1

From Azure's site:

Relay

The Service Bus Relay service enables you to build hybrid applications that run in both a Windows Azure datacenter and your own on-premises enterprise environment. The Service Bus relay facilitates this by enabling you to securely expose Windows Communication Foundation (WCF) services that reside within a corporate enterprise network to the public cloud, without having to open up a firewall connection or requiring intrusive changes to a corporate network infrastructure.

Relay also handle load balancing for you (you can have multiple applications listen at the same endpoint for the majority of the bindings).

Brokered Messaging

The second messaging solution, new in the latest release of the Service Bus, enables “brokered” messaging capabilities. These can be thought of as asynchronous, or decoupled messaging features that support publish-subscribe, temporal decoupling, and load balancing scenarios using the Service Bus messaging infrastructure. Decoupled communication has many advantages; for example, clients and servers can connect as needed and perform their operations in an asynchronous fashion.

Brokered messaging includes Queues and Topics / Subscriptions that allow you to send / receive messages asynchronously.

The main difference is that for relay, you have applications listening at an endpoint. When you send a message, the application processes that message when it is received. For brokered messaging, the message is stored when it is received by the client and can be processed at any time.

Answer 2

I think the main difference is the synchronous vs asynchronous nature of connectivity.

Where relay is mostly a firewall friendly way to expose web services to the public world (even behind firewalls, NAT devices, etc), messaging is more of a way to exchange in an asynchronous way messages over queues and topics. (look at it as the next version MSMQ with cloud support :))

Everything depends on the scenario, but if you are looking for - Routing (pub/sub) - Loose coupling sender & receiver - Load leveling Then you should definitely go for messaging.

If you want to make your service easily reachable for the outside world, relay service is your friend.