2

There are different approaches to implement brokered messaging communication between services using Service Bus Queues (Topics):

Which of those approaches are more useful in which cases?

Any comparison of performance, abstraction level, testability, flexibility or facilities would be great.

gnat
  • 6,213
  • 108
  • 53
  • 73
Vladimir Dorokhov
  • 3,784
  • 2
  • 23
  • 26
  • I think it would be more helpful if you had an actual scenario in mind, then others could help to demonstrate why one might be better than the other. At this point, your question is too broad. – Timothy Khouri May 30 '13 at 02:35
  • If it helps: image that we have worker role A and worker roles B and C. Worker role A publishes a messages through Service Bus Topic and roles B and C subscribes to that topic with different sunscriptions (SubscriptionB and SubscriptionC) and different filters (FilterB and FilterC). Which of those frameworks would you use to organize such communication, considering performance, scalability, cost, abstraction for developers? – Vladimir Dorokhov May 30 '13 at 07:35

1 Answers1

1

OK, now that I understand your question better, I see where the confusion is.

All 3 of the options that you are looking into are written by Microsoft.

Also, all 3 of those options are simply an abstraction - a client interface into the service that MS is providing.

None of them are faster, slower, etc. However, I would say that if you went the WCF route, then you can more easily abstract the technology choice a bit better.

What I mean by that is - you can develop a "GetMessage" contract in WCF that points to the service bus... and then later on change the design, and configure WCF to point to some other service and you wouldn't have to change the code.

So, that's one advantage for WCF.

That being said, CloudFX is built by Microsoft to give extra common functionality around the usage of the Azure Service Bus ... so don't ignore that. Look into the benefits of that API and decide if you and your team need those features.

Lastly, QueueClient is simply what CloudFX improves on, but adds no benefits like WCF. So you probably don't want to go with this route (considering your other 2 options).

Keep in mind that Azure uses a REST API under the hood for most of the communication... and so you might hit some unexpected performance issues if you don't configure your application correctly: http://tk.azurewebsites.net/2012/12/10/greatly-increase-the-performance-of-azure-storage-cloudblobclient/

Timothy Khouri
  • 31,315
  • 21
  • 88
  • 128
  • One of the key feature of the CloudFx is "A multi-threaded queue listener implementation optimized for storage transaction costs and performance."(http://msdn.microsoft.com/ru-ru/library/windowsazure/jj136818.aspx). So I thought, CloudFX could be more optimized library and speed up performance, isn't it? (Thanks for posting the link about improving performance here, I found it in your blog today as well) – Vladimir Dorokhov May 30 '13 at 13:12
  • All that means is that they've done some footwork for you. You could have written your own threading solution, also you could batch transactions together yourself. It all depends on your workload. So... if your workload calls for multi-threading and batched transactions, then looks like this one saves you 20 hours of coding :) – Timothy Khouri May 30 '13 at 21:45