I have a virtual machine on Azure which will listen to messages over the servicebus of Azure. And another developer needs to connect to this servicebus to send messages to my service. To do so, we need to come up with some protocol for this communication system. And I was thinking about using WSDL to make the server something webservice-like, but instead of listening to the standard HTTP ports it would connect to the service bus and within it a topic with subscription, or whatever. I'm still not sure what would be best.
So, is it possible? Has anyone done something similar before? Are there some examples?
Service Bus provides both Brokered and Relayed messaging models. With using Topics/Queues you are essentially sending and receiving message to/from the broker. So you can use APIs/protocols that the broker supports. As an example you can use the NetMessagingBinding from your service/client to send and receive messages through the queue. There is no contract here other than what you put in the BrokeredMessage body and properties values. The application on either end can decode/decipher that info as needed.
In the case of Relayed messaging however you are making a end-to-end connection between the client and the service with Service Bus serving as the proxy in-between for auth, location-transparency and even load-balancing. So here you can use from a variety of RelayBindings such as NetTcpRelayBinding or webHttpRelayBinding but then both the client and the service need to be available at the same time. Here you need the service and clients to be using the same contract.
Related
I am looking to rewrite a legacy windows based system to make use of Azure serverless features. Issue I have is that the system has to receive messages coming in via TCP due to the upstream system only supporting that approach. The upstream system then receives the ACK of the handshake as confirmation the message has been accepted.
Are there any Azure services that can accept a TCP message on a none standard port that I could then use to place the message on to an Azure queue? I have found some articles using Service Fabric but nothing less than 3 years old so wonder if there is a better way of doing it currently?
So you can use IoT Hub Protocol Gateway which can be the middle-man for accepting TCP\UDP messages which can then forward the message to Event\IoT Hub. You can then use Event Hub trigger in Azure Functions to process your messages.
You can deploy the Protocol Gateway on an Azure VM.
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.
Given the standard hybrid OnPrem/Cloud scenario where we have multiple OnPrem clients connecting to a service in the cloud, how can we service them all from a scaled out service (i.e. multiple listeners servicing multiple clients)?
Say we have a cloud service that implements the Hybrid Relay listener, and to service all of our clients we scale it out to N instances(up to 25). Clients get assigned to each instance via the documented load balancing feature so that each listener services a portion of the clients. What if we need to broadcast messages to all of the clients (like a chat application)? As far as I can tell, any single listener never has access to all of the client connections. Am I missing something?
I've used https://learn.microsoft.com/en-us/azure/service-bus-relay/relay-hybrid-connections-dotnet-get-started as an example to play around with this scenario by standing up multiple servers (listeners) with multiple clients (connections) connecting to each server, but there doesn't seem to be a way to broadcast or lookup ALL of the connections to the namespace, only the connections in the current listener scope.
but there doesn't seem to be a way to broadcast or lookup ALL of the connections to the namespace, only the connections in the current listener scope.
Message transfer of Azure Relay Hybrid is based on the connection. If a client is not connected to a server, we can't send message to the client from the server.
For the broadcast scenario, I suggest you use Azure Service Bus topics. After created a topic, you could subscribe this topic for all the clients. When we send a message to the topic, all the subscriptions will receive the message.
For how to use Azure Service Bus topics, link below is for your reference.
Get started with Service Bus topics(.NET)
I have a question that is confusing me what are the differences between the types of service bus, the brokered messaging and the relayed messaging? I am not looking for it from the development perspective but I want to understand more the concept and the differences between them.
Thank you.
Service Bus Relay and Service Bus Brokered Messaging are both mechanisms for developing distributed and hybrid applications. However, they target different development and access patterns.
Service Bus (SB) Relay provides a simple & secure way to do service remoting, i.e., it enables you to securely expose a service hosted on a private cloud to external clients. As is the case with service remoting scenarios, clients explicitly invoke the methods exposed by the "Relayed" service. The primary advantage of SB Relay is that the service can be exposed without requiring any changes to your Firewall settings or any intrusive changes to your corporate network infrastructure.
SB Brokered Messaging on the other hand provides a durable messaging platform with components such as Queues, Topics and Subscriptions. These can be used to implement complex patterns such as publish-subscribe and temporal decoupling between different parts of your application. Since the brokered messaging infrastructure can reliably store the messages, the senders and the receivers do not have to be online at the same time, or do not have to process the messages at the same pace.
Relayed messaging is thus appropriate for scenarios where you have a service that you want to expose to external clients. Clients interact with the "Relayed" service in the same manner that they would if they were on the local network, except that they access it via the SB Relay endpoint. Since this is a service remoting scenario, response is immediate subject to network latency. However, if for whatever reason the service is unavailable at that moment, the client's request will always fail.
In the case of brokered messaging, since the send & receive operations are decoupled, the sender can continue to send messages that are reliably stored on the service regardless of whether the receiver is online or not. However, the tradeoff for this resiliency is that the request will be processed subject to receiver's ability to retrieve and process the message.
I think the main difference is the synchronous vs asynchronous nature of connectivity.
Where relay is mostly a firewall friendly way to expose web services to the public world (even behind firewalls, NAT devices, etc), messaging is more of a way to exchange in an asynchronous way messages over queues and topics. (look at it as the next version MSMQ with cloud support :))
Everything depends on the scenario, but if you are looking for
- Routing (pub/sub)
- Loose coupling sender & receiver
- Load leveling
Then you should definitely go for messaging.
If you want to make your service easily reachable for the outside world, relay service is your friend.
From Azure's site:
Relay
The Service Bus Relay service enables you to build hybrid applications
that run in both a Windows Azure datacenter and your own on-premises
enterprise environment. The Service Bus relay facilitates this by
enabling you to securely expose Windows Communication Foundation (WCF)
services that reside within a corporate enterprise network to the
public cloud, without having to open up a firewall connection or
requiring intrusive changes to a corporate network infrastructure.
Relay also handle load balancing for you (you can have multiple applications listen at the same endpoint for the majority of the bindings).
Brokered Messaging
The second messaging solution, new in the latest release of the
Service Bus, enables “brokered” messaging capabilities. These can be
thought of as asynchronous, or decoupled messaging features that
support publish-subscribe, temporal decoupling, and load balancing
scenarios using the Service Bus messaging infrastructure. Decoupled
communication has many advantages; for example, clients and servers
can connect as needed and perform their operations in an asynchronous
fashion.
Brokered messaging includes Queues and Topics / Subscriptions that allow you to send / receive messages asynchronously.
The main difference is that for relay, you have applications listening at an endpoint. When you send a message, the application processes that message when it is received. For brokered messaging, the message is stored when it is received by the client and can be processed at any time.
I’m designing a backend that allows users to establish a TCP socket with it and send/receive stuff along this socket (using a pseudo-protocol I’ve made up) in real-time.
It has to be scalable – i.e. architected on a cloud host. Currently I’m evaluating Windows Azure.
To achieve scalability the application will run on several Web Role Instances. Meaning the users’ TCP sockets will be split across several instances (via a load balancer).
This backend is an event-driven application – when a user sends something to it the message should be passed on to all other connected users.
This means there must be a reliable way to send messages from one Web Role Instance to all other Web Role Instances. As far as I understand, this is what inter-role communication refers to.
Using Service Bus, is it possible for all Web Role Instances to subscribe to a Topic and publish messages to it? Thus implementing the event-driven requirements of my distributed application?
(If not then I’ve misunderstood what this article is about: http://windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/)
I wanted to find this out before delving too deep into learning C#, .NET and Windows Azure development.
Thank you for your help.
Yes, using the service bus, all the web roles could send messages to a single topic and each role could have unique individual subscriptions to that topic, such that they all receive the messages sent.
Clemens Vaster has implemented an extension to SignalR using the service bus. It is possible that SignalR + the Service Bus may meet the needs of your project, including the TCP socket implementation.
http://vasters.com/clemensv/2012/02/13/SignalR+Powered+By+Service+Bus.aspx