[douche]

Hmm, I submitted this yesterday, but it got lost in the scrum.

It's always interesting to hear real reports from the trenches that aren't essentially ads for technology XYZ. I'm afraid that all too often, we make things more complicated for bad reasons; whether ignorance, chasing the latest trend, or resume-driven-development...

[robertlagrant]

Message-oriented stuff has been around a long time, so I don't think it's a fad.

It's basically taking the concept of "integration" (or API) itself and creating a product for it, just as a database is a product for the concept of persistence. Thus just as not every application has to reinvent a database, with a messaging product not every product has to reinvent queueing up integration calls if the target system isn't available.

The article also mentions request-reply being "what you really want", I think that this is a) not true, as a lot of the time you can fire and forget, and b) when you need it the products generally provide a request-reply API on top of their lower-level APIs. No need to reinvent.

[scaryclam]

I got the impression that the author didn't really want a message based system at all, but rather a request response system that they tried to impliment within a message broker. Of course that's going to create more headaches than it solves; it's the wrong solution.

Both message brokers and request-response code have their places in distributed systems, but they really need to learn when each is appropriate.

I agree, saying that request-reply is "what you really want" was kind of silly, especially after the opening paragraph that states "it depends".

[ambicapter]

Can you elucidate the differences between message-broker and request-response use cases in your eyes?

[marcosdumay]

In my eyes (where the GP makes perfect sense), a message broker is asynchronous, there's no implicit wait while your consumers work on our request. A request-response interface will stop the producer until the consumer is done.