DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Why Some People Think Messaging Is More Scaleable

Why Some People Think Messaging Is More Scaleable

Michael Mainguy user avatar by
Michael Mainguy
·
Mar. 21, 12 · Java Zone · Interview
Like (0)
Save
Tweet
4.77K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Web Service Message oriented middleware Notion (music software) Phrase (software) Aspect (computer programming) Durability (database systems) Library Middleware

Published at DZone with permission of Michael Mainguy, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Purpose-Driven Microservice Design
  • Troubleshooting HTTP 502 Bad Gateway in AWS EBS
  • What Is High Cardinality?
  • 5 Best JavaScript Web Development Frameworks

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo