Windows Azure Service Bus oder Azure Connect

31. August 2011 15:26

Mit dem Windows Azure Service Bus und Windows Azure Connect bietet die Windows Azure Plattform 2 Möglichkeiten für die Kommunikation bzw. den Informationsaustausch von Applikationen.

Sehr oft stellt sich dann bei der Architektur von Lösungen die Frage, welche der beiden Möglichkeiten die bessere ist. Da diese Fragestellung auch sehr häufig an uns herangetragen wird, hat sich das Windows Azure Customer Advisory Team entschlossen, einen entsprechenden Blogbeitrag dafür zu erstellen.

Grundsätzlich ist bei der Wahl einer der beiden Komponenten bzw. Services das Kommunikationsmuster, das die zu verbindenden Applikationen nutzen, zu berücksichtigen.

Scenario	Communication Source	Communication Destination	Windows Azure Service Bus	Windows Azure Connect
On-Premises	On-premises client	On-premises server	Server registers with Service Bus as a part of opening the service host, client communicates with Service Bus endpoint.	Ensure client and server local endpoints are within common endpoint groups (Note 1).
Hybrid	On-premises client	Azure hosted server	The Azure instance registers with the Service Bus as a part of opening the service host. The client communicates with the Service Bus endpoint.	Ensure endpoint Groups of on-premise Computers contain links to Azure Roles. (Note 1).
Hybrid	Azure hosted client	On-premise server	The server registers with the Service Bus as a part of opening the service host. The Azure instance creates a client that communicates with the Service Bus endpoint.	Ensure that the client Azure role and the server local endpoint are within common endpoint groups (Note 1).
Cloud	Azure hosted client	Azure hosted server	The Azure server instance registers with the Service Bus as a part of opening the service host. The Azure instance creates a client that communicates with the Service Bus endpoint.	Connect does not provide connectivity between Roles or Role instances.

Der vollständige und umfassende Artikel befindet sich am Windows Azure Customer Advisory Team Blog.

Fazit des Artikels (übernommen vom Blog)

In conclusion, here are some useful observations that can help you in the selection process.

If Interoperability with non-Microsoft platforms is important to your scenario, you should use the Service Bus because its message queuing functionality enables connectivity from any REST-enabled HTTP clients.
Azure inter-role communication is not supported with Windows Azure Connect, so if this is a requirement you may want to use Service Bus as explained here. (For more information, see Overview of Enabling Communication for Role Instances).
For scenarios where your required protocols might change, and you don’t know what they are in advance, Windows Azure Connect is the best choice because enabling new protocols boils down to configuring application firewall rules to enable communication.
Roles are limited in the number of internal and input endpoints they can define, so if you are likely to exceed these limits (currently no more than five endpoints), you should consider Windows Azure Connect which will remove your need to define specific endpoints.
There is no need to define input or internal endpoints for Azure hosted services communicating with either the Service Bus or Windows Azure Connect, as both rely on making outgoing connections via their own transport channels and ports.
If you require a simplified approach to enabling access to network services like Active Directory supporting integrated security when communicating to SQL Server instances hosted on-premises, or accessing network file shares, you should use Windows Azure Connect. While it is possible to make the Service Bus support any custom protocol exchanging binary data, this is significantly more complex than simply enabling Windows Azure Connect.
Windows Azure Connect requires that on-premise machines install the WA Connect Agent, which means that that they must be running Windows. There is currently no support for looping in non-Windows based machines or network devices.