🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
what is different between amqp request-reply and rest request-reply?
Answers
-
On PubSub+ Broker HTTP/REST is used in "Fire and Forget"/async mode, it's a one way communication protocol only. So you can't do Request/REPLY over HTTP/REST
REST Can be used in two ways with Solace :- HTTP POST on host:port/TOPIC/YourTopic, your http client will only receive an empty response with HTTP 200
- RDP (REST Delivery Point), it's Solace name for webhook.
- It's a Solace Queue with subscriptions to one to many topics
- the messages that are capture by the queue are send as HTTP POST to an endpoint that you define. Host/port and URI are configurable. You can use the message topic level to build the HTTP REST URI
- With HTTP you can only sent one message and wait for the HTTP 200. It's not a connected protocol such a Solace SMF or AMQP/MQTT. Those connected protocol can ACK multiple message at a time, which give better throughput even with high latency link
- HTTP should be considered when there's no other available option. It's not a protocol well suited for messaging, while SMF, AMQP or MQTT are.
Example : if you're coding in PHP for example, where's there's no Daemon running all the time, you could HTTP POST to solace an event, have some microservices processing the event and use RDP to get the processing result back as an HTTP POST sent to your PHP server using RDP.
AMQP Request Reply : a queue is dynamically provided so that your requester get the reply.
Check this tutorial :
AMQP link is bidirectionnal.
Is it amqp request-reply consider async ?
I would say no, since you're client is blocked until you'll get the response.
But the other side, the code that process the request and produce the reply, it can be async, scale up and down, use the benefit of the broker for guaranteed messaging (no message loss), Partitioned Queue to ensure messages are processed "in order" while being able to scale the number of microservice processing the requets0 -
Hi @Thomas Manson , I have few questions
1) If requester is sending request using amqp protocol, will the requester/client be blocked until receive response ? Initially , I thought the requestor will not be blocked while waiting for response for the request.
2) How about Microgateway service in PubSub+ Broker (HTTP REST - support put/delete/get method )? Is it still a "Fire and Forget"/async mode? What do you mean cannot do Request/REPLY over HTTP/REST?
0 -
2) How about Microgateway service in PubSub+ Broker (HTTP REST - support put/delete/get method )? Is it still a "Fire and Forget"/async mode? What do you mean cannot do Request/REPLY over HTTP/REST?Correct @dreamoka, I read @Thomas Manson's response and was about to pop in and say don't forget about Microgateway mode. That does allow for request/response via REST. But note that you set it for the entire messaging service or VPN, so that might prevent you from using it.
If it is an option for you, then @Aaron has created some great content over the years re: microgateway that might help.
- Codelab here:
- Docs/Aaron interview video here:
1 -
1/ The tutorial is showing JMS/AMQP example and the call is blocking for a configurable amount of time :
Message reply = context.createConsumer(replyToQueue).receive(REPLY_TIMEOUT_MS);If you look at other protocol like SMF, you can use both blocking and non blocking request :
2/ you're right, I forgot about the microgateway. if the broker is configured in a microgateway mode, you can get request/reply behavior.
I've not used it myself, so I just know the theory about it 😅
0 -
1) If requester is sending request using amqp protocol, will the requester/client be blocked until receive response ? Initially , I thought the requestor will not be blocked while waiting for response for the request.
On the AMQP client side it really depends on the capabilities of the library that you choose. Solace doesn't provide an AMQP library, we just support the amqp v1 protocol so you would choose what client lib you want. The apache qpid ones are probably the most popular from what I've seen.
1 -
Yeah. I agree. it really depends on the capabilities of the library that AMQP client is using.
As I using RHEA Promise for my nodejs project -https://github.com/amqp/rhea-promise, the requestor does not block while waiting for response for the request.
2
