Why would you want to use windows service bus, hosted in Azure or on premise? The best answer is that it makes communication easy between your applications.
How many times have you had to roll your own message queues in an SQL Table? How often do you configure replication between databases? Do you have multiple applications that need to be aware of changes occurring elsewhere? That is the key role of the Windows Service Bus.
Think of the service bus as a centralized broker for the communication of a meaningful transaction. Applications may publish actions to the service bus. They may also subscribe to transactions that may be published to the service bus. As a result, any application can subscribe to any event published on the service bus. Additionally, multiple clients may subscribe to the same event occurring on the service bus. They can subscribe in competing form, resulting in load balancing. They can subscribe individually, resulting in distributed activities.
A common scenario may be that your CRM application generates a lead. That data is stored in the CRM database. A message may be sent to the service bus for the new activity. Later, the data warehouse ETL process picks up that message from the service bus, and adds the event to the lead summary in the warehouse storage. The CRM application is not aware of the data warehouse utilization of its data. The data warehouse doesn’t know how to connect to anything other than the service bus. This lose connection allows extensions to be maintained without applications having discrete knowledge of one another.
The Windows Service Bus is available for self-hosted systems, or for use in Azure. This makes your application hosting choices very flexible, allowing you to choose the best option for your situation.
For more info take a look at the documentation at MSDN.
Cheers,
Ben