The need has come in which we have to consume data coming from a 3rd party in which they have an Amazon SQS instance setup on top of the AMQP protocol. They have given us the following:
queue name
user name
password
port
virtualhost
host
We are a cloud-born company in which we host everything in the Azure cloud, e.g. web services, web apps, databases, etc.
I would like to find out the following:
What "service" should I design or develop on from Azure that can consume messages from an Amazon SQS?
If Azure Service Bus supports AMQP 1.0 and Amazon SQS supports AMQP 0.9.3, can this be a plausible path?
I guess my question is more related on how to architect my solution. I know there are frameworks like RabbitMQ, but would like to avoid the VM path. If solutions like RabbitMQ are the way to go, can only the "consumer" pieces be utilized and not the "server" pieces of RabbitMQ implemented?
Any and all advice will be greatly appreciated.
Related
I am implementing some real-time, collaborative features in an ASP.NET Web API based application using WebSockets and things are working fine when the app is deployed on a single web server.
When it is deployed on a farm behind a software (or hardware) load-balancer, I would like implement the pub-sub pattern to make any changes happening on one of the web servers invoke the same logic to check and push those changes via websocket to the clients connected to any of the other web servers.
I understand that this can be done if there an additional layer using RabbitMQ, Redis or some such pub/sub or messaging component.
But is there a way to use DNS or TCP broadcast or something that is already available on the Windows Server/IIS to publish the message to all the other sibling web-servers in the cluster?
No.
But you can use MSMQ instead of RabbitMQ, but still that's not really going to help as it's a queue and not pub/sub so ignore that.
If it's SignalR you're using there are plenty of docs on how to scale out like Introduction to Scaleout in SignalR
Even if it's not SignalR then you can probably get some ideas from there.
Assume you want to deploy 2 apps of which one provides some API to the second application.
With services I'd just bind the service (or declare it as dependency in my manifest) to my application and hence get the information regarding host, port and credentials passed to my application (e.g. via env variables in node.js). Is there a similiar mechanism for application to application "communication"?
So far my approach is to use a RabbitMQ service (or any message broker/queue) which both applications are bound to and which I then use for cross-app communication.
Thanks!
Using a message broker, as you do, is definitely a viable solution. This allows for asynchronous communication. Yet you will have to take care of authentication yourself, as opposed to app <-> service communication, where authentication/authorization is established through through cloudfoundry service binding.
Another way would be to use a service registry for this. Both apps would register with the service registry and be able to discover each other.
You could try spring cloud service registry (Eureka) or consul. As for your message broker solution, this will not generate credentials for your apps, as a cloudfoundry service binding does.
From your use case, for microservice to microservice discovery, you need Spring Cloud Services and Eureka.
I don't have much experience on nodejs. But some googling, will give you some articles. Here's one that may help you - https://www.npmjs.com/package/eureka-js-client
This article will give you an overview from Java and Spring perspective - https://spring.io/guides/gs/service-registration-and-discovery/.
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’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