I have a passion for talking to people, identifying problems, and writing software. When I'm doing my job correctly, software is easy to use, easy to understand, and easy to write... in that order. Michael is a DZone MVB and is not an employee of DZone and has posted 48 posts at DZone. You can read more from them at their website. View Full User Profile

Why Some People Think Messaging Is More Scaleable

03.20.2012
| 3996 views |
  • submit to reddit

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.

Published at DZone with permission of Michael Mainguy, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Senthil Balakrishnan replied on Wed, 2012/03/21 - 8:50am

Interesting article...

Reasons could be,

 

  1. The long history of messaging for ages now.
  2. Sole purpose of messaging is integration between systems in a asynch. way & seen as a cleaner solution than HTTP.
  3. The routing, location transparency & fail safe (communication is durable/persisted). Even though having a ESB can just fill in this gap.

 

Note: HTTP thread pool is shared (by both synch. & asyc. calls), from a deployment stand point deploying a user interacting web applications(with SLA) on the same server as async. services may not be a good idea IMHO. I don't deny the fact this is just a deployment concern & not HTTP async. as solution.

Ronald Miura replied on Wed, 2012/03/21 - 9:27am

HTTP is synchronous. You can use it transport for messages that are passed to an asynchronous execution engine, but then you're just implementing your own messaging system, without the qualities of a good messaging system.

That said, a simple HTTP->worker thread async engine is more than enough to the scalability needs of most applications, and people often overestimate their need for scalability when choosing technologies.

Jonathan Fisher replied on Wed, 2012/03/21 - 10:01am

Build first, then profile, then find your scalability problems. If you minimize the amount of architecture you create up front, avoid writing your own frameworks, you'll be able to scale out of the park.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.