I am currently using Netty integrated WebSocket to do a chat room, I would like to ask whether Netty supports STOMP protocol, so that Netty+ WebSocket + STOMP can be done? I can't find any examples online because the combination doesn't fit the actual development, or because they're the wrong combination?
Netty provides a STOMP codec so in that sense it "supports" STOMP. However, STOMP is a messaging protocol and Netty is not a message broker. Therefore, in that sense Netty doesn't support STOMP. In order to support STOMP as a messaging protocol you'd have to implement much more than what Netty provides. See the STOMP specification for more details on that.
Related
I am working on an NIO SMTP client with Spring Webflux and Reactor Netty. I have a requirement to integrate messaging into the application, and I was wondering if there is a non blocking way to interact with ActiveMQ, the only documentation I found that mentions NIO in ActiveMQ only talks about how the ActiveMQ server uses NIO model, but nothing about consuming the service with a non blocking client.
Sure, ActiveMQ, like any other JMS provider has a blocking API (MessageConsumer.receive()) as well as a method to setup a MessageListener that is called automatically once a message arrives. Since you are using Spring, take a look at this example.
In addition, you can enable server-side NIO with 'nio' instead of the tcp prefix: nio://hostname:port?key=value, see also https://activemq.apache.org/nio-transport-reference, but it sounds like NIO is implemented only the server end of a client-server communication only.
I want to subscribe to a Java Messaging Service (JMS) publish-subscribe service using Apache Qpid. However rather than using Java, I want to use C++. My customer told me this was possible (and even said trivial). Are they correct? Can anyone point me to an example? Everywhere I've looked says that to use JMS I have to use Java. The point here is that the service is a third party service (so I can't change it to use AMQP or any other protocol other than JMS).
This depends quite a bit on what JMS Broker you are using. If the broker supports the AMQP 1.0 protocol as well as whatever native protocol it implements for its JMS client then you might be in luck.
The main thing you need besides support for AMQP 1.0 then is good cross protocol communication support such that a message send from the JMS client can get turned into something meaningful for the subscribed AMQP client or the other way round the broker needs to map incoming AMQP messages into meaningful JMS representations so that the two interoperate successfully.
A Broker like ActiveMQ does support this sort of thing along with support for other protocols as well. You need to have the AMQP support turned on in the broker and then you can use the C++ client from the Qpid project to send messages and receive messages with relative ease.
I've learned a respectable amount about networking protocols in Grad School and in professional experience and sent HTTP requests programmatically using AJAX and such.
The project on which I work professionally uses JMS to communicate and I'm curious about how it works.
When using REST (for instance) one makes an HTTP request with parameters in either the URI or the message header in order to invoke a service and further describe its needs.
A mentor of mine at work and I were discussing how JMS works and I'm struggling to understand at an application level how messages are actually sent. As far as I understand JMS in general (I realize there are many implementations of JMS) it is a specification for how to format data being sent.
Is the message itself still sent via HTTP(S)? Could it be SMTP?
Without going excruciatingly deep I would like to understand how one would, at a code level, send a JMS message from one service to another?
Am I even thinking about this correctly?
Can it be done any number of different ways?
Is there a convention that's used in the industry?
If someone could shed some light on JMS for me I would appreciate it.
Thanks!
JMS is not a protocol, it's an API specification. It's not something like TCP or HTTP protocol. Simply put the JMS specification defines signature of messaging APIs. How the APIs are internally implemented and what protocols they use to communicate with the messaging provider is vendor specific.
The vendor specific JMS implementations know how to communicate with their own messaging provider, but not with any other vendors messaging providers. For example IBM's MQ JMS implementation uses it's own protocol to communicate with IBM MQ Queue Manager, similarly Oracle JMS, Active MQ implementations with their own messaging provider.
Hope this helped.
I'm trying to implement bi-directional communication between java-based client and server and the main protocol is JMS. But due to administrative intranet restrictions where client reside it is not possible to have inbound connection. The main idea is to wrap JMS in something HTTP-like. I chose Websockets. The only solution I found is OpenMQ. It supports this. Are there any better solution?
Thanks.
JMS is a way different way of communication compared to websockets. Briefly :
Websockets are an implementation of sockets for the Web. A socket is a connection that is made between 2 peers. The connection is on hold, while the peers exchange messages. The connection is maintained during the whole communication and it is closed after the communication has ended.
JMS is a Java standard/API for sending messages between 2 or more clients. However, it is differently structured. In JMS, there is an entity called message broker, where messages are sent, stored and then retrieved by the clients. So, this approach can be a distributed environment.
So, JMS is a different approach to Websockets, since JMS is "stateless" and optionally asynchronous, while websockets are stateful and synchronous.
Thus, I think you should not make a choice between those 2, considering only the firewall limitation, but you should be more focused on the context of the 2 approaches, deciding which one is more suitable for your case.
If you believe that JMS is a better solution, then you should alter the firewall rules, so that the port used for JMS (by default 1099) is allowed with specific security limitations.
Otherwise, you can use websockets, accepting the performance limitation of synchronous communication.
There is also the approach of integrating websockets with JMS, that is captured by openMQ and other frameworks. However, I do not know what the implications in performance will be compared to simple JMS, and I think that this solution should be chosen, only if we talk about a web application.
Additional Comment
There is also the capability of using HTTP tuneling over JMS. Thus, you will not have to use websockets. You will still use JMS, but there will be a servlet that will be receiving HTTP requests and redirecting them to the JMS service. This has also been implemented in openMQ, as you can see in the tutorial. In this way, you ovveride the firewall restriction, without adding the complexity of websockets.
I am looking for an example or code snippets on using Spring's STOMP topic pub/sub messaging, with both the client and server in the same tomcat7 instance. NOT OVER THE WEBSOCKET.
We want to handle some operations asynchronously in our server side and so want to use STOMP as our messaging protocol in our tomcat7 instance. Everywhere I look I find samples for STOMP over websocket or integrating with other MOM's!!
Anyone know about a java sample for simple spring stomp pub/sub? Appreciate any pointers...Thanks.
Have a look at the Spring Websocket Portfolio application. Yes, I know you said not over websocket, but the application has some tests that use a STOMP client/server that might just be what you are looking for.