Sending messages to light-weight client at customer sites

Question

Short version:

Our Azure application needs to notify client software running on-premise at 500 customer sites whenever new data is available for them. Data is made available on customer-basis. Some may receive data 50 times a day, others once a month. We control the software running both in Azure and locally at the customer site, but the mechanism to notify the customers must only require that the customer is set up in our application in Azure, and that the customer runs through a configuration wizard (username/password) in our on-premise app.  Is there something in Azure to solve this type of problem smoothly?

Longer version:
We have an application running in Windows Azure. We process "data" for our customers in this application. Our customers have a small client application running in their offices (created by us), which regularly calls one of our web services in Azure to retrieve this data. Originally, our customers did this polling of data every 15'th minute. Then requirement changed, and it went down to 1 minute. As one can expect, the now want to lower it to 5 seconds. Of course, we don't want to have 500 customers calling our web service once every 5'th second juts to check if some data is available for them.

What I would like to do is to implement a mechanism where we can inform the software running in the customer's offices that data is available, so that they don't have to poll every 5:th second. I wonder if any of the functionality in AppFabric can be uesd for this. It would be nice if we could call a web service directly at the customer site, but they obviously have firewalls blocking this.

New customers are added all the time, and one requirement is that adding a new customer should not require any manual set up except for running through a few wizards in our software online. In other words, it won't work that someone has to log on Azure Management Portal and configure something. Another requirement is that the customer should not have to do any manual configuration except for entering their user name and password in the client app. I assume that each customer would need their own authentication information for whatever system we use to notify the customers about new data being available.

I looked at AppFabric Service Bus a while back (year ago) but I have gotten the impression that the authentication mechanisms used in ASB is a bit 'static' in that you set up something (a namespace?) in Azure and then use this when setting up the server/client. If you have 500 clients and each needs their own authentication details, it seemed like I would need to create 500 namespaces or something like that.

---

Nitramafve

Answer 1

Your question is more related to ACS then to SB and the good news is that Clemens did a really awesome presentation on this topic

http://channel9.msdn.com/posts/Securing-Service-Bus-with-ACS

In short: you'll need probablly one namespace, with one or more topic and 500 subscriptions. For all of these things (including the creation of service identities) there's a really simple API so you can tie it all in your code without the need for manual portal creation of anything.

Again, check out Clemen's presentation - all the answers are there :)

Answer 2

SignalR + service bus may be the solution to your question. It would do away with client side polling.
http://vasters.com/clemensv/2012/02/13/SignalR+Powered+By+Service+Bus.aspx