http://activemq.apache.org/websockets.html says that these guys have implemented stomp over web sockets functionality. How is it different for the normal web sockets solution provided by Dojo's cometd? I thought web socket spec defines its own message structure and all? How does the HTTP upgraded web socket differs from this stomp over websockets? Would really appreciate some expert opinion guys.
Thanks,
Bhanu
The cometd implementation uses the Bayeux protocol, while the Apache implementation uses WebSockets.
Related
I've been recently learning about vertx and websocket.
What I understood that you can have real-time application using them, but I didn't understand the difference between them
A websocket lets you push messages from server to client and vice-versa, encouraging the publish-subscribe methodology. Then what is vertx doing? It acts as an event bus and also encourages publish-subscribe model.
I can be completely wrong in my analysis, hence please correct me and I'll be glad. thanks.
WebSockets is a stateful protocol, usually used to communicate between clients and servers.
Vert.x is a server-side framework, which has a very good support for WebSockets.
You don't have to use WebSockets with Vert.x. But if you do want to use WebSockets, Vert.x is a great option.
Here's an article I wrote a few months ago about both:
https://medium.com/#alexey.soshin/playing-ping-pong-over-websockets-with-vert-x-447c634c6c87
Recently I am working with along with IOT department, right our project is on discussion and creating core architecture of an application. client specification is we must use MQTT protocol to communicate between device and java application (eclipse paho client).
its a web application based on spring boot and microservice architecture. but I an not able to find any good solution for API gateways that provide MQTT support.
I found zuul is good but do we have any alternative like kong..
MQTT is a TCP stream based protocol, so API Gateways that operate on the HTTP / Layer 7 are not going to fit the bill.
There are extensions to commercial API Gateways available, such as the Axway MQTT Proxy described here.
While not an API Gateway, Confluent also have a MQTT proxy that allows simple integration with Kafka, however if you have already written an application that implements the backend then Kafka is going to require some re-architecting.
The other options are really going for a simple TCP stream reverse proxy like nginx or HAProxy.
If I was asked to build something like this, I'd go straight to Kafka. It and MQTT are a very neat architectural fit and also operate very well together but it really depends on your requirements.
I need to implement a real-time scenario via web sockets and ZeroMQ queue.
SockJS with Stomp in the client side
Spring MVC / Integration with #EnableWebSocketMessageBroker
Remote messaging queue with ZeroMQ
At this moement, I could connect client and Spring via web sockets but I need to add the magic of remote queues.
ZeroMQ is available from 2 remote URLs (one for publishing and another one for subscribing).
My question is: How can I implement ZeroMQ in order to stay listening subscribed URL or the publishing URL?
Additionally, this type of functionality is conceptually similar to Spring Integration Outbound Gateways which stay listening for the response. Is it possible to implement ZeroMQ via Spring integration?
Thank you
We have an open JIRA issue to add ZeroMQ support to Spring Integration.
But nothing is implemented yet; contributions are welcome!.
SignalR documentation says:
SignalR uses the new WebSocket transport where available, and falls back to older transports where necessary
Does Fleck have something like this or it uses always own implementation?
No, Fleck is just a Websocket component. You can use XSocket.net, it has long polling fallback.
I heard a guy from IBM give a talk about MQTT and he said that MQTT is the most lightweight messaging protocol as of today. His argument was that the smallest overhead produced for a single message is 2 bytes. However, I've heard the very same (2 bytes overhead) about HTML5 WebSockets too? Anyways, as I plan to use Open MQ as a JMS provider for a messaging application, which protocol my provider use became of interest to me. I cannot anywhere find the answer to that question and I even googled the Open MQ documentation and the documentation of GlassFish which use Open MQ as a JMS provider. Some blog posts and the like on Internet says AMQP but I cannot find a solid reference to back that statement up.
Which protocol does Open MQ use, and how would you know?
I think you mix a few things up: MQTT is an application level protocol and uses TCP as transport protocol. MQTT can also be used with Websockets as transport. MQTT is, if you will, a lightweight alternative to JMS and AMQP.
AMQP is a popular and reliable alternative to JMS and is well suited for business and mission critical messaging. It is very feature rich and widely used. Note that AMQP is a messaging protocol while JMS is an API (which can even use AMQP as transport). You can use AMQP directly in Java Applications with Libraries such as the RabbitMQ Java Client.
MQTT on the other hand is perfect fit for telemetry data and scenarios where you have many clients which communicate with a single message broker and where low bandwidth usage, memory efficiency and battery life on the clients is key.
JMS does not define any transport protocol (in contrast to MQTT) and anything could be used here. I personally think TCP is a good fit here, too.
I do not know about OpenMQ but for JMS and AMQP I can recommend ActiveMQ. For MQTT there are a few brokers out there including HiveMQ and Mosquitto.
Obligatory Disclaimer: I am a developer of HiveMQ, so I am probably a bit biased ;-)
I think OpenMQ is using STOMP as Application Level Protocl. There is no other documentation which protocol OpenMQ supports than STOMP.
Edit: found the UMS Protocol and it seems OpenMQ is using this per default. https://mq.java.net/4.3-content/ums/umsIntro.html
OpenMQ is not able to use AMQP so I would recommend RabbitMQ.