4 ms·
This just isn't accurate. Messaging solutions have always supported request-reply. Just as examples, https://activemq.apache.org/how-should-i-implement-request
by wmfiv 7y ago
This just isn't accurate. Messaging solutions have always supported request-reply. Just as examples,
https://activemq.apache.org/how-should-i-implement-request-response-with-jms.html https://activemq.apache.org/how-should-i-implement-request-r...
https://nats.io/documentation/concepts/nats-req-rep/ https://nats.io/documentation/concepts/nats-req-rep/
https://www.rabbitmq.com/direct-reply-to.html https://www.rabbitmq.com/direct-reply-to.html
- gshulegaard 7y agoI may be off but asynchronously queuing two messages and implementing a synchronous block in business logic does not sound the same to me as a TCP request response cycle.
- rroeserr 7y agoTCP doesn't have a request/response cycle - its a stream of bytes between applications
- gshulegaard 7y agoCorrect but TCP provides a reliable data stream between two hosts, the (particular) messaging protocol over it wasn't part of what I was trying to point out.
- VectorLock 7y agoWhile its certainly possible to use in this mode from what I've experienced most people who deploy applications at scale use an async message bus/queue rather than a request/response. At that point is there even much of a benefit vs. simply using a synchronous request/response oriented service?