Why some people think messaging is more scaleable

I've often been around (or in the middle) of debates about how message oriented middleware is more scaleable than web services. The problem with this debate is that it is a false dichotomy. There is no reason you cannot do asynchronous http services where the response is simply "Yep, I got it". In practice, these services are just as scaleable and flexible as their queue based brothers and typically are not nearly as complex.

Some of the reason this propaganda gets started is that non-technical folks need to be told a reason why a particular technology is more appropriate. Folks will often use "hot button" phrases like "it's more scaleable" instead of trying to actually explain in nitty gritty detail what the real reason is.

Additionally, making asynchronous web services is truly a bit more challenging. The APIs for JMS foster the notion that the message is transmitted and immediately returns. HTTP libraries typically espouse the idea that you care about the response and therefor tend to be a bit more RMI-like.

A final and perhaps not least important reason is that when someone says "JMS", everyone else hears "Asynchronous". When someone says "HTTP", most people assume "Synchronous". Using technologies in a common manner is a good way to foster effective communication. Innovation is good, but having a shared context and terminology makes communication much simpler. Put another way, sometimes a clever solution is much worse than a simple one, especially when trying to communication the idea to someone else.

Both JMS and HTTP can be used to create scaleable solutions, when deciding on JMS, don't put TOO much emphasis on scaleability, but focus on other aspect like durability or manageability. Almost any technology can be made scaleable with a little thought. You just have to decide if the cost to think about an alternative is worth more or less than the cost of the knee-jerk solution.

Comments

Anonymous said…
JMS provides transactions and recoverabilty out of the box. You'd have to write a complete layer on top of HTTP to get that level of reliability.
Plus JMS has a push-mechanism (at least from the developer's point of view) for the answer.
So, in an enterprise environment, JMS still wins hands down.
earcam said…
In addition to previous comment, JMS (and messaging in general) decouple the producer-consumer allowing for ... scalability. I can have multiple consumers, which scales well.

(yes you can do the same with load balancing etc but come on, at this point you're building a messaging system over webservices).

Messaging is more scalable than direct invocation (or any half cocked async webservice malarky) - that isn't what some people think, it's fact.
Mike Mainguy said…
Do transactions and recoverability make JMS more scaleable? Your comment illustrates the problem I observe when talking about this sort of thing. JMS doesn't "win hands down" when you don't need the extra things you're talking about...

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

Installing virtualbox guest additions on Centos 7 minimal image