SOAP and High Performance: An Oxymoron?
XML messaging using the SOAP protocol has become the lingua franca for interoperability. But it is not suited for high-performance messaging, writes GemStone Chief Architect Jags Ramnarayan on his blog. Like others, Ramnarayan sees benefits in the emergence of a language-neutral data architecture that allows applications to be built in the language that best fits their needs.Ramnarayan does not just take on SOAP, he takes a few jabs at messaging solutions proper, including IBM MQ.
Instead of requiring application developers to think about messages being the mechanism to share information, why not let them use the same paradigm they use when communicating between various components within the application; simply share domain objects in common data structures like a Map and use native thread based notification services. Extend this concept such that these data structures are distributed and visible to disparate applications. Essentially, applications share data and events with each other through a shared object database that is distributed in nature. Applications perform CRUD operations on a database and receive notifications when changes to data they are interested in occur.
In a detailed discussion, Ramnarayan also talks about REST. In the future, he says, reliable, asynchronous messaging semantics placed on top of REST [Web services based on REST] could be ‘’something to watch out for. ‘’
http://jagslog.blogspot.com/2007/07/high-performance-data-sharing-between-c.html
July 31st, 2007 at 2:31 pm
No, this view is not entirely correct…
SOAP by itself has no performance issue,
http://webservices.sys-con.com/read/250512.htm
July 31st, 2007 at 3:08 pm
Hmm … sounds like a reinvention of JINI/JavaSpaces.
July 31st, 2007 at 9:16 pm
The word is interoperability. In the pragmatic world, across vendor frameworks, various standards and platforms, SOAP services the interoperability problem very well. Performance is a consideration, but when two systems can not communicate with each other, performance is not the first NFR to be considered.
In summary I guess, sometime performance is a trade-off for interoperability
July 31st, 2007 at 9:22 pm
ICE? YAML? JSON?
Take your pick!
But anyone who thinks that 3k of deep-nested XML in a SOAP envelope t to send a basic 1-string snippet of information between 2 apps “does not have a performance issue” needs their head read!
July 31st, 2007 at 9:25 pm
Okay maybe 3k is a slight overstatement. But 1/2 - 1k would be correct! That’s still way too much overhead.
The corrected title of this posting should read: “SOAP and high-performance: a moron”.
– Dave
August 1st, 2007 at 1:07 pm
You missed the point…
Use-cases will drive the decision. If you have a business critical service requiring integration with a multitude of client platforms (from VB6 client apps to IBM MQSeries), the *safest* bet is a SOAP Service over HTTP. On the other-hand (the article example - financial services) where performance has a much higher priority - SOAP payload may not be a consideration. Simply put SOAP serves a need, however there are other solutions to other problems too.