WebFlux allows for reactive HTTP client and server operations, and does a fantastic job at that. However, it seems like the spring-jms module doesn't provide similar functionality for listening and publishing to JMS brokers using reactive streams. Given the close match between the JMS messaging model of a stream of messages and Reactor's model of a stream of events, this seems like a real missed opportunity.
Comment From: snicoll
this seems like a real missed opportunity.
The JMS API is blocking at its core. Can you please describe in more details what you mean by "close match"?
Comment From: Diagoras
@snicoll You're correct that it's blocking, but JMS sending and receiving both seem to map pretty well to a stream of events. Much of Spring Integration is also blocking, but has provided support for converting to and from a Flux since its domain matches the same event stream model.
For example, given a JmsTemplate it'd be nice to be able to do something like:
JmsTemplate receive = ...
JmsTemplate send = ...
Flux<Message> messages = jmsTemplate.receiveAsFlux(destination);
messages.map(SomeClass::someMethod).subscribe(send.asSubscriber(otherDestination));
Both the "receiveAsFlux" and "asSubcriber" methods would obviously have to defer to a blocking threadpool, and I'm sure there might be a better way to provide that functionality than adding methods to JmsTemplate. But the core idea is to mimic Spring Integration by adding convenient functionality for listening to JMS messages with a Flux<Message>, and for pushing messages to a broker from a Flux<Message>. While it might be blocking, we can still have a back-pressuring stream that easily integrates with other reactive tools.
Comment From: bclozel
As mentioned by Stephane, JMS is blocking at its core and it doesn't make sense to implement a variant that would claim reactive streams compatibility when in fact backpressure is not honored.
You might be interested in reactive streams adapters shipped by Spring Integration, as well as support for other libraries.