Using REST with ActiveMQ (OT)

Posted by PhilF on 19-Apr-2017 08:31

Here's a general question --

Are any of you successfully using REST to communicate with ActiveMQ? Do you have any problems with this?

The background, for those who want more context:

We have an ABL application that communicates with our client's software using a REST interface via PASOE. Their software is based on Apache Camel, so I suggested that they should use ActiveMQ to communicate for improved reliability. It turns out I opened a can of worms.

I now need to recode our interface to speak directly (JMS) with a pair of ActiveMQ queues. I don't have a problem with that in principle. (though in practice, I am having lots of problems with that!) But it seems to me that the reason from running any MQ is that it can provide reliable communication with your legacy software -- even if you cannot recode that software. So I asked why not just use the existing REST interface via ActiveMQ, and this is the answer I got:

[quote]

REST in ActiveMQ does not look like viable solution(we tested), it is not a recommended practice, for consuming messages.

Blog-> http://activemq.2283324.n4.nabble.com/activeMQ-topics-via-rest-missing-messages-td4677698.html

REST and JMS protocols are notably different; REST is one-message-per-connection while JMS is many-messages-per-connnection
JMS subscriptions are dropped when the connection is dropped. For Topics, this means missed messages. For queues, this means less efficiency (for both client and broker) and less fairness of message delivery if both JMS and REST consumers are used.
REST can lead to dropped messages; if the message is consumed by the activemq internal consumer and then the REST connection drops before the client receives that message, it will be lost. So, JMS message delivery guarantees are weakened.
The REST implementation in the broker caches a consumer. Any messages prefetched to that consumer will remain stuck indefinitely until a REST client requests it. If a REST client uses the built-in session management, and the session that creates the internal consumer is removed, that internal consumer will be abandoned, leading to stuck messages.
With Topics, regardless of the consumer prefetch, messages will be stored in the broker's memory for the subscription. If the REST client is lost or away for a long time, those messages could starve the broker for memory.

[/quote]

I confess I don't understand all of this -- partly due to my ignorance of the ActiveMQ architecture. And ultimately, it's not my place to dictate the architecture. But it doesn't feel right; if REST was a bad thing to do in ActiveMQ, I would think I'd find a lot of discussion and documentation on that.

Thanks for your comments.

OpenEdge General - Forum

Posted by thunderfoot79 on 19-Apr-2017 10:31

You don't see a lot of discussion on this because they are considered two different solutions. Rest is http and used to interact with web services.

This helps a bit on the explanation.

stackoverflow.com/.../jms-vs-webservices

My personal opinion,

If you want a read/response interaction, go back to the Rest endpoint and connect up with the OpenEdge.Net.PL library provided you are using 11.6.3.

If you want a post to a single endpoint, I prefer the Rest endpoint as well for these scenarios.

If you want multiple endpoints for the same message without a response needed, that is where JMS really shines. In that case use the Stomp interface as referenced by cverbiest. It works very well with AMQ.

JMS can also work very well when you need to traverse multiple firewalls.

All Replies

Posted by cverbiest on 19-Apr-2017 09:10

Does it have to be rest ?

there is an ABL stomp interface bitbucket.org/.../overview

Posted by thunderfoot79 on 19-Apr-2017 10:31

You don't see a lot of discussion on this because they are considered two different solutions. Rest is http and used to interact with web services.

This helps a bit on the explanation.

stackoverflow.com/.../jms-vs-webservices

My personal opinion,

If you want a read/response interaction, go back to the Rest endpoint and connect up with the OpenEdge.Net.PL library provided you are using 11.6.3.

If you want a post to a single endpoint, I prefer the Rest endpoint as well for these scenarios.

JMS can also work very well when you need to traverse multiple firewalls.

Posted by PhilF on 19-Apr-2017 12:50

I'm not in charge of the architecture. We created a REST interface to meet their spec, and that's what they would want to use. Is there an reliability advantage to using stomp with ActiveMQ? (I know there is a licensing advantage; you can code it without an AppServer. But we already have PAS, so that's not an issue.)

Posted by PhilF on 19-Apr-2017 15:22

Thanks.

Our spec matches the REST / web services model; there is a certain amount of error checking that is done on each call -- so a response is required. Their JMS replacement design involves two queues - one for input and one for output.

I had thought that ActiveMQ would simply act as middleware -- providing a reliable way of passing messages, handling the queue/retry. (Does STOMP to MQ manage the retries?) For our REST calls to them, I would still have to queue and retry. (Which to me means that there is no point in going through ActiveMQ for these.) But can't ActiveMQ make REST calls to us, and manage the retry on failure?

Posted by PhilF on 19-Apr-2017 15:26

> connect up with the OpenEdge.Net.PL library

Since we need to listen as well as call, aren't we better off going through PAS -- at least for the listeners? [Edited for clarity]

Posted by thunderfoot79 on 20-Apr-2017 08:07

Yes you would want to use PAS for the service and not the library I detailed(that is for connecting from ABL). I misunderstood which side had the listening portion.

As for reliability between AMQ and a Rest service, both will have quarks you probably will have to work through for reliability. Once past that, both are very reliable. In the end, do what you are most comfortable with as both methods will work.

This thread is closed