I am working on a Windows Phone 8 app which is connected to Azure Service Bus Relay. Since i cant add Microsoft.ServiceBus.dll to the WP8 project, I had to go with BasicHttpBinding which works fine.
Now I want to use the service bus relay with topics in WP8. Is this even possible? I cant use NamespaceManager which is discussed here: http://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-topics/ , because its not supported by WP8.
My question is simply, is this possible to do? And what approach should i choose?
We do not have any libraries that target Windows Phone at this point but are working on producing these. You can make direct http calls to the REST APIs and send/receive messages etc. Samples for these are available:
http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-569cff88
https://github.com/WindowsAzure/azure-sdk-for-java/tree/master/microsoft-azure-api/src/main/java/com/microsoft/windowsazure/services/ServiceBus
http://msdn.microsoft.com/en-us/library/hh780762.aspx
Zeezer,
"Now I want to use the service bus relay with topics in WP8"
Not sure if you are conflating two separate issues...
We do not have an SDK for Service Bus Relay for the Windows Phone. However, if your service is using any of the *HttpRelayBinding's, you can use a regular HTTP client from the Windows Phone app to communicate with the Relay endpoint for your service. You will need to include the ACS token for authenticating to Service Bus Relay in a custom HTTP header called ServiceBusAuthorization.
Related
There is very limited information on azure signalR service. I need to clarify a question so any help would be highly appreciated.
how azure signalR service actually scale out ? I mean, as far I have worked on it. it seems that you have to include a primary key of azure signalR service to your hub. you can host you hub anywhere. So how hub scales out.?
SignalR Service manages all the client connections, as well as certain state information such as group membership. Your ASP.NET Core application establishes a connection to the SignalR Service instance.
When the application wants to send a message to connected clients, it uses this connection to instruct the service to do so. The service can also invoke hub methods via this connection.
You can read more about the service protocol.
When a client initiates a connection, it calls a negotiate endpoint on your ASP.NET Core application, which redirects the client to connect to the SignalR Service instance instead.
Because the ASP.NET Core application only needs to execute hub logic and most of the heavy lifting is done by SignalR Service, your application does not typically have to scale out to handle more SignalR connections. You can scale it based on the needs of the web traffic (serving web API and MVC requests, for example), and you can scale the service based on the needs of your SignalR traffic.
This is the documentation that I found and followed to have a signalr hub that worked across multiple App Service instances but behaving as a single hub.
You need to create a "backplane" in Azure using Storage queues and topics.
Details here: https://learn.microsoft.com/en-us/aspnet/signalr/overview/performance/scaleout-with-windows-azure-service-bus
#anthonychu is this still needed / applicable??
I'm reading the very limited information about Azure SignalR service as well as the quick start guide and want to make sure I'm understanding this correctly.
We still seem to have a hub and if I understand this correctly, the function of Azure SignalR service is to simply push the messages to connected clients.
In my case, I store the history of chat so by hitting the hub first, I'm able to still use my backend logic to persist chat history or do any other processing that I may want. Then simply allow Azure SignalR service to push the data to connected clients.
The main benefit seems to be handling the scaling of the service.
Am I getting this right?
Yes, you are totally right.
You will use exactly the same API of ASP.NET Core SignalR to write your business logics, which means you can persist whatever you want when the messages from clients hit your hubs.
Azure SignalR Service will be the underlying transport between your app server and connected clients. For example, when you want to broadcast messages to all your clients, you actually only send one message to Azure SignalR Service and the service will broadcast the message to all clients for you. So that you don't have to worry about the scale-out. Azure SignalR Service will handle the scaling-out for you.
You understand correctly.
SignalR is not yet ready for production (when speaking about ASP.NET Core), SignalR for ASP.NET MVC has been around for a while (stable).
SignalR consists of 2 pieces: server and client. The server is as you describe: a "hub" that you can use to push information to clients.
On a webpage you load a piece of generated javascript (generated automatically from your hub definitions). Basically you let your website visitors (clients) connect to the hub through signalR's mechanism (signalR will choose the proper way to connect depending on the browser), and then 'subscribe' to the different methods you have active in your hub.
The workings are simple: whenever you call code in your hub (can be from clients, or from backend code) communication is automatically handled for you to all subscribed clients.
Note: If you are running this on an azure web app: enable the "always on" setting, and set the "websockets" toggle to "enabled", otherwise you'll see strange behaviour.
Note2: The RC version for signalR core 1.0 has just been released (7th of may 2018) so it might be a while before this software starts becoming stable and available through the public nuget/npm channels.
We've been writing services to access our on-premises databases through Azure Service Bus Relay for awhile now. That means that we've had to deploy them as WCF services. Our web site development is moving to node.js and I would like to begin deploying our API services on node as well. However, while the Azure NPM package has good support for queues/topics on Azure Service Bus, I can find no mention of the relaying capabilities. I've had a look at the code for the Azure SDK on github, but again, relay seems to be conspicuously absent.
Is it possible to use Azure Service Bus Relay with a node.js backend?
Now Azure support Node.js. You can find the infomration from here. This link is the samples for Node.js.
Right now, Relay only supports a WCF service. You can try to use Clemens Vasters' post on Port Bridge to get your scenario working. In his post, he describes creating a WCF client / service that will forward requests to a specific port.
I currently designing a solution for communication between a Charge Point for Electrical Vehicles and the backoffice. the ChargePoint are connected to the Network of the Telephone company and the backoffice is hosted on Azure. The Chargepoint don't have a public IP-address. In order to send messagese from the backoffice to the ChargePoint we want to implement Azure Service Bus (ASB) Relay. The ChargePoint OS is embeded Linux and Azure is Microsoft. The ASB Relay only works with WCF bindings. I found out that mono supports WCF but cann't find if it supports httpRelayBinding?
what kind of communication are you looking for between the device and service? If you need Relay like two-way or one-way synchronous RPC communication then you could use a simple http client to call into the service, a sample for this is here: http://code.msdn.microsoft.com/windowsazure/Relayed-Messaging-Bindings-a6477ba0
Also if you are looking for different patterns of communication such a brokered messaging where you can send/receive messages w/ data then you can consider using Service Bus Queues and Topics. I recently covered some of these usage scenarios in my session at TechEd: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B336
I have a Windows Azure Mobile Service up and running, however, there is a need for that service to consume some data expose through an external SOAP service and store that information in the mobile service database.
I would like to set up a worker in the mobile service, so the calls to the external SOAP service are executed in a fixed period of time.
I've been looking for a solution to this problem, but haven't found anything yet. So any help that would get me in the right direction would be appreciated.
Unfortunately there isn't an easy way to talk to a SOAP service from your Mobile Service backend. The backend is based on Node.js, and even though there are some Node modules for talking to SOAP services, they are currently not supported in Mobile Services. We are working on a solution that will enable you to use any Node module in your service, but it is not out yet.
If you control the SOAP service and it is written using WCF, you may be able to easily add a REST endpoint to the service with just a few config changes and then consume it from your Mobile Service via plain HTTP requests by using the "request" module.