52

Besides the asynchronous/synchronous nature of a particular problem and taking into account that MOMs (in this case having chosen JMS) offer additional features for free like load balancing and others, what else can one consider when choosing JMS rather than REST or vice-versa?

Thanks

Stephen P
  • 14,422
  • 2
  • 43
  • 67
jmdev
  • 729
  • 1
  • 6
  • 13
  • 2
    These are two different technologies and patterns.... and as a result your question makes no sense. – Nix Mar 08 '12 at 19:19
  • 9
    @Nix don't be such a pedant. From an application integration point of view, it's is perfectly valid to consider a REST based approach or a MOM based approach. If anything, I'm surprised SOAP services weren't being considered as well. – Tom Howard Mar 09 '12 at 11:07
  • 2
    @Nix I can achieve the the same integration by using either technologies, for this reason the question is prefect valid. in fact a great question. – Junchen Liu Nov 18 '15 at 11:35
  • 3
    I think this is a constructive question, and fine for SO -- it should be reopened. It has two answers, one with 30 up votes, and the question itself has 20 up votes -- which seems constructive to me. – Software Engineer May 13 '16 at 03:19

2 Answers2

55

Always use REST. It is the most modern, advanced and scalable integration approach available today. Load balancing a REST based service is achieved simply with hardware or software HTTP load balancer and can be considered just as free as load balancing in JMS.

MOM (Message Oriented Middleware) doesn't scale easily (but may scale big enough for your needs). REST works at web scale.

MOM does not have economies of scale. For data retrieval requests, each time a particular piece of data is requested, another message must be sent to the server and responded to by the server. In a REST based system, requests for the same data can be serviced by a HTTP cache. This means that as the volume of requests increase over time, a MOM based system will see the server load increase at the same rate as the requests. A REST based system will see the the server load increase at a slower rate than the requests.

MOM will tempt you with fire-and-forget messages with guaranteed delivery, only to bite you with the chain of custody problem.

MOM is terrible for synchronous request-reply as it will fail slowly (i.e. wait for timeout) when the server is down. When a request is going to fail, you want it to fail fast. A HTTP request to a REST based service will fail immediately (on the TCP connect) if the server is down.

MOM is useful for asynchronous request-reply messaging, but then you'll be left with the problem of where to store the state in-between the request and the reply (Hint: Your options are File or Regular Database, the Message or a NoSQL Database). Often the extra implementation effort is not worth the perceived advantages of asynchronicity. Also REST based services do support asynchronous requests if you really need it. 202 Accepted is your friend in this situation.

Finally, the use of caching allows REST based systems to implement pull-based integrations, which are far easier to support. For instance, just say we want to move data from system A to system B. The MOM approach would be to send messages from A to B. A REST based approach would be to create a data feed service in A (like an RSS feed) that B polls for new data (the same way your RSS reader polls for new articles). When B fails, in the MOM example, the support team will need to monitor the message queues to make sure they don't overflow, while someone else get's B back up. In the REST example, the support team just has to worry about getting B back up. There isn't much of a difference when A fails. In the MOM example B doesn't know and doesn't care. In the REST example B does know that A is down, but it still doesn't care because obviously there is no new data from A when it's down. Initially the polling that pull-based integration requires seams very inefficient, however HTTP caching makes this a non-issue.

In other words, instead of investing in a JMS server, invest in a good caching HTTP load balancer.

RevanthKrishnaKumar V.
  • 1,855
  • 1
  • 21
  • 34
Tom Howard
  • 6,516
  • 35
  • 58
  • 33
    "Always use REST" is a terrible answer. There are certainly many valid cases where REST is the more appropriate choice, but there are also many others where MOM is the better choice. – Paul Legato May 29 '13 at 19:26
  • 1
    @PaulLegato I've been working in the MOM space for over a decade. It's my bread-and-butter and it sucks. Gimmie an example where MOM is a better technical choice than REST. – Tom Howard May 30 '13 at 06:44
  • @TomHoward: What if the message receiver is not available when a message is posted? Then in this case, REST cannot do this since REST is synchronous. – tonga Oct 29 '13 at 15:15
  • 4
    @tonga: What happens when your messaging infrastructure is not available? For cacheable responses, a HTTP cache in between the sender and receiver can respond when the receiver is unavailable. Otherwise the [Circuit Breaker pattern](http://springinpractice.com/2010/07/06/annotation-based-circuit-breakers-with-spring) is a viable (and preferable) alternative, especially considering the chain-of-custody problem that asynchronous messaging presents (literally last week I had to help manage yet another production incident because a receiver could not process an asynchronous message). – Tom Howard Oct 30 '13 at 05:34
  • 4
    @TomHoward +1 for the strong opinion and it really makes sense. – Firdous Amir Apr 01 '15 at 21:54
  • Hm I think its a really good post but i wonder if you can really say REST is ALWAYS the best. What a bout a publish subscribe scenario where thes one publisher and many subscriber and the publisher doesnt know the subscriber? Does it really make sense to implement that using REST and the Publisher is starting Feeds on multiple subscriber? Isnt it much easier to use JMS and the Publisher doesnt have to care? Especially when its only low amount of data you can just store in the message... – Hannes Jul 07 '16 at 08:02
  • 1
    There are cases in which the chain of custody problem is irrelevant. In many cases, there's no caching possible at all (when every message is the equivalent of a new POST). A JMS running on a cluster is as reliable and resilient to failure as a cluster of web servers serving stateless applications, only, additionally to plain web servers, it solves one difficult problem, which you'd have to solve manually otherwise: guaranteed delivery to a single member of a consumer pool, in spite of the distributed JMS cluster. "Always use REST" is definitely an overstatement. – user625488 Jul 07 '16 at 08:54
  • @user625488, if you are right, then I look forward to our new JMS overlords taking the internet by storm. Oh wait... my answer is over 4 years old and JMS is still a rarity on the internet. I guess there must be some reason for that. – Tom Howard Jul 07 '16 at 21:42
  • @Tom Howard Who said anything about the Internet? In the original question, I mean. – user625488 Jul 08 '16 at 12:06
  • 1
    @user625488, if JMS had the benefits you say it does, then we would expect to see lot's of JMS services on the internet. The fact that we don't tell us a lot about it's fitness compared to other approaches. – Tom Howard Jul 11 '16 at 13:14
  • 1
    @Tom Howard You don't see a lot of JMS on the public Internet. You see a lot of it, however, on intranets. Not because it's the best possible solution, but because there's nothing competing with it in its niche. Again, there was no mention about the Internet in the original question, even if you keep bringing it into the discussion. – user625488 Jul 12 '16 at 16:42
  • 1
    @user625488, intranets are a distorted market, where competition is artificially constrained. Many places I worked, integration using JMS or another MOM was compulsory and yes, in that sort of environment JMS and MOM thrive. The reason I keep referring to the internet is because you don't get artificial constraints in that market. If there were benefits of using JMS or MOM over REST, then you would see more JMS or MOM interfaces on the internet. Even if it was for specific niches, you'd see it there. The fact that we don't is very telling and you ignore the market at your own risk. – Tom Howard Jul 14 '16 at 13:15
  • So because you dislike a market, for an IMO not objective reason, you choose to disregard it, even it it's apparently irrelevant to the original question. Right? Competition isn't artificially constrained on intranets, it's constrained by business requirements about continuity and manageability. No company would refrain from switching technology if that switch came with no cost. I don't think I ignore a market or another. I just think you have to adapt to the market you're selling in, instead of trying to impose your own rules or preferences on it. – user625488 Jul 27 '16 at 10:53
  • @user625488, I don't dislike the intranet markets, I simply recognise that they are distorted. This approach is fairly standard; If you find yourself trading in a market and want to be successful, you look to what works in larger equivalent unconstrained markets. Then you look at your market to understand what constraints are in place that would hinder using the successful the approach from the larger market. Do those constraints add value? In this case, I argue they do not. e.g., IMO JMS confers no continuity and manageability benefits compared to REST. – Tom Howard Jul 27 '16 at 21:52
  • Hey @user625488 is it just me or have you also seen JMS dying off or dead all over the place? Asking for a friend. – Tom Howard Jul 27 '18 at 13:34
  • @TomHoward JMS yes, but not necessarily messaging in general. Only, it's relegated to the backend/intranet/preparation of data, rather than being publicly visible. With all the IoT stuff being adopted by various industries such as manufacturing or energy production, messaging is very much alive. With good reason not JMS: other than web sockets, there's not much in the way of messaging that browsers support, and JMS is very strongly Java-bound. But MQTT or STOMP - alternative messaging protocols - do have client implementations available for browser-based clients. – user625488 Jul 29 '18 at 06:37
  • 3
    Well, 'always use REST' is a bit overarching. It depends, as always. I'm working in the stock trading world and the classic use case for MOM is one price (e.g. MSFT) needs to go to 500 terminals and systems on a trading floor as fast as possible. How do you do that ? UDP multicast, which is supported by the better MOM's. REST API would mean 500 terminals requesting the current price, once every 10 milliseconds ? I think for all cases of real 'push computing' MOM topics is a good architecture. You never need queues. – Axel Podehl Jan 18 '19 at 08:05
  • @AxelPodehl, I was expecting to see another poorly thought out reason for using MOM, but I was pleasantly surprised. You’re 100% correct. When latency needs to be less than 100ms MOM is better. – Tom Howard Jan 20 '19 at 05:20
  • 2
    @TomHoward, yep, and just taking a random low-latency benchmark from 2011 to show where we are at: 2.5 million messages/second with a mean latency of 13 microseconds (http://ateam.purrdigital.com/dell-touts-performance-of-its-tibco-ftl-stack/) - I didn't do this one, so I can't vouch for its validity though.. – Axel Podehl Jan 21 '19 at 08:25
26

You can't compare these two technologies.

REST is a service/pattern to give you an organized way to access a stateless resources.

MOM Systems/JMS is a pattern designed aroubd sharing messages between systems. Its about data in, data out in a reliable fashion.

You can't really compare JMS to REST because they solve different problems.

But if your question is more along the lines of do I need a REST interface for my JMS queues? Its all situation, I have seen people use REST to shield thin clients from the logic nessessary to queue messages in JMS. E.g. if you have an android client that wants to talk JMS, its a lot harder to do that naitvely versus pushing messages to a "rest" interface which can then translates and push to a JMS.

gtonic
  • 2,295
  • 1
  • 24
  • 32
Nix
  • 57,072
  • 29
  • 149
  • 198
  • You can share reliably data between systems using REST. Atom feeds are a perfect example of this. – Tom Howard Mar 12 '12 at 00:28
  • 1
    I'm not saying you can't. Thats the whole purpose of REST. – Nix Mar 12 '12 at 11:41
  • 3
    "MOM Sysems/JMS is a pattern designed aroubd sharing messages between systems." I'm saying REST is really good at that. IMO you can very easily compare JMS to REST as they both look to solve application integration problems. Do you have an example of *anything* that is better solved with JMS than a RESTful approach? – Tom Howard Mar 12 '12 at 19:25
  • 2
    @Tom Howard you have a pool of sensors that push messages to JMS, and a pool of consumers processing those messages. You want each message to be handled exactly once. You have no way of splitting the message stream so that each slice receives approximately the same number of messages, there's no way of telling which message will take how much time to be processed. You absolutely can solve this with REST endpoints alone, but it's way easier with JMS. – user625488 Jul 07 '16 at 08:58
  • @user625488, you want "each message to be handled exactly once" I hear you say? Sounds like you'll have a chain-of-custody problem if you use JMS with fire-and-forget. I recommend you use an [RFC5005 archive feed](http://tools.ietf.org/html/rfc5005#section-4) based solution instead. – Tom Howard Jul 07 '16 at 21:46
  • 1
    @Tom Howard but all consumers shall poll regularly your archive feed generating useless traffic, with JMS consulmers can be wake up to handle new messages. It also depends on your client technology, web-based or rich client with local object graph storage. – Sébastien B. Feb 10 '17 at 09:34
  • @SébastienB. Are you suggesting no resources are consumed when the consumers are connected to the JMS server? How well does JMS scale. Can it handle 10K consumers? What about 100K? What about 1M? With a REST based approach, you can put use `Cache-Control: max-age=1, public` on the head of your feed. That means that will 1M subscribers polling every second, you feed will only get 1 request per second. The rest of the requests will be served from cache. With the JMS, your JMS infrastructure would need to support 1M long lived TCP connections. Good luck with that. – Tom Howard Feb 10 '17 at 12:43
  • @Tom Howard Yes you are right for thousand of consumers but if you only have a reasonable number of consumers, you can avoid polling and maintain long living tcp connections to receive immediate notifications especially if the number of update is small why saturate network with polling request?. Both technologies are complementary. Check this benchmark to see jms performances: http://hiramchirino.com/stomp-benchmark/ec2-c1.xlarge/index.html For some applications it could be largely enough – Sébastien B. Feb 10 '17 at 13:49