How do I fetch individual messages to multiple clients, from the Azure Service Bus relay, without having to have a namespace for each client?
Background:
I have a web service, which has multiple users, which are businesses. Not a huge number, but a few hundred. The users are mostly on NATs and behind firewalls, so I created a Windows Service to be installed on the users local machine, and that service listens to a Azure Service Bus Relay Service.
How can I deliver individual messages to these users/clients via the service bus relay? Do I have to create a new namespace on the service bus for each user? Or is there something smarter than that I can do?
Thanks!
This was answered well over at the Windows Azure forum on MSDN:
http://social.msdn.microsoft.com/Forums/en-US/windowsazureconnectivity/thread/235c1515-d507-4b78-9d84-9e04a49e038b
Related
I have inherited an azure service bus solution - C#, Web Api with Singleton service implementing the queue. Running locally on my PC, I can publish a message to my Dev queue and see that event consumed by my service bus receiver. No problem.
In our staging environment however my receiver is not firing so my code never processes the messages. I found an instance where a different environment was pointing to the staging queue purely by luck which makes me think "what else is using this queue". We have no application logging (useless I know) of when events are published or consumed so I wondered, is there a way from within Azure to see either
What is consuming the events published to the queue, or
What is currently connected to the queue so I can validate each connection and make sure a dev in a far flung office isn't running test programs using the queue.
Thanks
Create application insights instance
Connect your web app in azure to the created AI
after some time you will be able to see requests to other systems sent by your app (in application map you'll see fancy diagram of requests, in logs you can query requests to service bus)
Drop the AI instance if you don't need it anymore
I have a WIP chat tool with SignalR hub running on my server and would like to add translation feature to it.
So far I set up Azure Translator Text API, Service Bus and Functions. And I've made the SignalR server casts messages to the service bus, then the function triggers upon existing messages on the bus, and posts it to the translator api.
Flow of Messages
[Users' Browser] -> [SignalR Hub] -> [Service Bus] -> [Functions] -> [Translator API]
Here my concerns are:
What is the advantage of using service bus or functions? It is also possible to directly post messages to translator API from my server, but I assume service bus make it easier when I want to scale out my server, is that correct?
Related to 1., I know there's Service Bus Relay that enables two systems directly communicate to each other. Is this useful for this kind of project?
Where should the messages translated through functions be posted back to? The SignalR hub on my server, or the service bus with some tag that distinguishes whether the message is raw or translated?
I never used the Azure. Now, i with a problem.
I am going to do a Chat on Xamarin Forms using SignalR. So, the chat will have a 1:1 and a group 1:all . Its for a small group of 700 to 1.000 persons. Looking at the internet, i didnt understand if i have to pay for Azure App Service (standard) + Azure Bus Service, or just Azure Bus Service, or just Azure App Service.
Short answer: you only need to pay for Azure App Service to create a single Web App if you want to use SignalR.
The only reason you'll need Service Bus is if you decide to scale your Web App to multiple instances. To synchronize across multiple web apps, SignalR requires a messaging backplane. That's what Service Bus would be used for. Your other options for a SignalR messaging backplane are Redis (very fast), or Azure SQL (slower). I personally use Service Bus for my SignalR messaging backplane. But again, you do NOT need Service Bus if you're only using one instance for your web app.
If you have an MSDN account you get a certain amount of free credits to put towards it, but each type of Azure Service generally has a charge. Check out the pricing pages on azure and you'll be able to gauge which is your best option, alternatively if you aren't ties to Microsoft, then you can look at the RabbitMQ offerings of Amazon.
If you're unsure on the pricing, speak to a Microsoft Sales person, they've helped me out in the past and are quite good.
I am trying to figure out which Azure service to use to create a distributed application. The application consists of
A desktop (Windows) application which is fetching, manipulating and storing data in Azure
A backend which stores data and does background processing.
A web front-end which allows me to view the data and trigger background processing in the backend
Any number of desktop application instances can connect to the backend and access the same data
The desktop application and the web application will send and receive data to the backend. Each message can be up to 100 MB (images etc).
The Azure universe is a bit overwhelming, and I'm trying to find out how to set this up.
My initial thought is to let the desktop application communicate with an Azure Cloud Service with WCF. The cloud service is set up with a WCF web role. A separate web application (web role?) is communicating with the same WCF web role.
The WCF role will also start worker roles to do more heavy, time-consuming processing.
Any ideas and insight is welcome! :)
For WCF service and web front-end you can use both Azure Cloud Service or App Services - it mostly depends if you need to install some 3rd party components on the machine (Azure Cloud Service allows you to do that).
For background processing use Web Job in App Services or worker role in the Cloud Service. You should also use some queue (I like more Service Bus then Azure Queue from storage account). Your worker role or Web Job should monitor this queue and when you put some message to it then some background processing should be triggered. Background processing could be done also in WCF process itself, but using worker roles or Web Jobs allows you to provide more availability.
For storing blobs (like images) definitely use Microsoft Storage (Blobs), for other data you can use Sql Database or something quite new: DocumentDB. Sql Database is simpler to use and easier to migrate data to other servers etc. but is more expensive.
And of course you can do the same on Virtual Machines, but I guess it wasn't something that you asked for :)
I read that Signalr on Azure requires a service bus implementation (e.g. https://github.com/SignalR/SignalR/wiki/Azure-service-bus) for scalability purpose.
However, my server only makes callbacks to a single client (the caller):
// Invoke a method on the calling client
Caller.addMessage(data);
If don't need Signalr's broadcasting functionality, is an underlaying service bus still necessary?
The Service Bus dependency is not something specific to Azure. Any time you have multiple servers in play, some of your signalR clients will have created their connection to a specific server. If you want to keep multiple servers in sync something needs to handle the server to server real time communication. The pub-sub model of service bus lines up with this requirement quite well.
dfowleR lists a specific case of this in the comments. Make sure you read down that far!
If you are running on a single server (without the sla on Azure) signalR will work just fine on a Cloud Service Web Role as well as the new Azure Web Sites. I did a screencast on this simple scenario that does not take on a service bus dependency, but only runs on a single server.
In order to support the load balance scenario, is it possible to enstablish a "server to server" SignalR PersistConnection between multiple instances (ie on Azure) ?
If so, we can use a SQL Azure Table where all instances register at startup, so newest can connect to previous ones.