BUSted! A quick comparison of Azure Service Bus and Service Bus for Windows Server

BUSted! A quick comparison of Azure Service Bus and Service Bus for Windows Server

  • Comments 4

 

A while ago I was asked to do a simple comparison between Service Bus for Windows Server (SBWS) and Azure Service Bus (ASB) so I thought I’d share this with you all.   Most of this stuff is probably obvious.  A more detailed comparison is available here and is well worth a read.

Installation and support

  • ASB: Since ASB is a cloud-based service there is no software to install and support is provided by Microsoft. OS and application patching and updating is also handled by Microsoft. Storage is provided by and managed by Microsoft. Backups and business continuity of ASB itself is managed by Microsoft.
  • SBWS: SBWS runs on-premises and must be installed and configured on a Server 2013 or Server 2008 R2 machine (you can also install it on Win7 or Win8 for individual developer usage). SQL Server 2012 or 2008 is also required (Enterprise or Express versions). OS and application patching and updating must be handled by a local support team. Storage is provided by SQL Server and must be managed by a local support team. Backups and business continuity must be managed by a local support team.

Message Relays

  • ASB: ASB’s relay service supports direct one-way messaging, request/response messaging, and peer-to-peer messaging.
  • SBWS: At the time of this writing SBWS did not support relayed messaging.

Security

  • ASB: Solutions deployed in Azure using ASB can make use of Azure’s security token service known as ACS (Access Control Service). ACS is a cloud-based authentication and authorization service that integrates with standards-based identity providers such as enterprise Active Directory, and web identities like Windows Live ID, Google, Yahoo!, and Facebook.
  • SBWS: Solutions deployed on-premises using SBWS can make use of the Service Bus Security Token Service (SBSTS) which is fully integrated with the Windows security model. SBSTS can issue self-signed Simple Web Tokens (SWTs) using Windows identities.

Quotas/runtime settings

  • ASB: Options regarding message and queue sizes are fixed due to the multi-tenant nature of ASB.  ASB Queue/Topic sizes can be up to 5 GB.  Messages can be up to 256K.  See here for specifics on ASB quotas.
  • SBWS: SBWS provides much greater freedom for configuring runtime settings and message and queue sizes.   SBWS Queue/Topic sizes can be up to 10 GB.  Messages can be up to 50MB.    See here for specifics on SBWS quotas.

Network latency

  • ASB: Network and security latencies may impact performance, especially when moving messages from on-premises to cloud or cloud to on-premises. Throughput could also be impacted by unexpected spikes in unrelated internet traffic.
  • SBWS: Administrators have much more control over their own network’s traffic and routing, thereby enabling more efficient bandwidth usage and throughput.

Addressing schemas

  • ASB: ASB Namespaces are fixed – all endpoints have a Service Bus postfix added to the URL to ensure uniqueness.
  • SBWS: SBWS uses fully qualified domain names (FQDN) or a mapped DNS entry to represent service namespaces.

Instances

  • ASB: In ASB there is only one "instance" of the service available and it is managed by Microsoft.
  • SBWS: With SBWS it is possible to have several on-premises SBWS servers via self-hosted servers or third-party providers.

Leave a Comment
  • Please add 1 and 6 and type the answer here:
  • Post
  • Wow, I did not know there is Windows Server Service Bus. Most of the info out there is the Azure Service Bus. Sometimes it seems like MS is putting too much software out and seeing what sticks ;-)

  • Kris,

    Service Bus for Windows Server (SBWS) is a set of installable components that provide many of the messaging capabilities of Windows Azure Service Bus (cloud)on Windows Server (on-premises).  This helps ease transitions to the cloud (minimizes the risk of code churn) while also enable on-prem testing of code that will be deployed to the cloud.  See msdn.microsoft.com/.../jj193027(v=azure.10).aspx for a nice overview of SBWS.

    John

  • Thanks John. I am going to explore this in a bit detail as I am working on a Biztalk project that requires some queuing capability. My initial implementation choice was MSMQ. But I am going to explore this more and if it is an good choice will definitely consider this. If you have any experiences with regard to the same, please chime in. Also do you think there is/will be an adapter for Biztalk 2010?

  • I'm not aware of a BizTalk SBWS adapter but this article would probably provide some great tips for you.  

    msdn.microsoft.com/.../hh542796.aspx

Page 1 of 1 (4 items)