Davanum Srinivas has released a comparison of Axis1 and Axis2 performance, that shows a 4x-5x improvement from Axis1 to Axis2, and shows a fairly well-done comparison between the two versions of Axis.
The numbers in this article show that modern XML/SOAP design (pull parsing, streamlining, minimising data copy) have a big effect. How much further do you think XML/Java performance can go? And how good is good enough? At what point is XML fast enough to replace proprietary binary protocols - if ever?

That blog article is not a good comparison because:
1) that is a really old version of xfire, since then we've had major speedups.
2) it is on a computer with a slow memory bus, which becomes the limiting factor. The computer Dims tested on is much faster in that respect. (800Mhz vs 400Mhz)
3) If you do large amounts of output you'll see that JAXB 2 performs much better than xmlbeans or ADB, since it does all sorts of crazy output optimizations.
XFire should perform similar, if not better, to Axis 2. I believe Dims did some testing as well of XFire, I'd be curious to know what those numbers are.

I don't agree with this at all. We had a scenario where we wanted to call WebLogic workflows from an ASP .Net client. We had 3 different approachs: a CORBA based bridge product, a different .Net remoting based bridge product and web services. The bridge products took quite a bit of time to integrate and code whereas the web service was generated instantly with a right-click. We ran extensive stress tests on the three methods and the difference in time was negligible.

< We ran extensive stress tests on the three methods and the difference in time was negligible.</blockquote>
Of course it will be if logic execution time on server is 100 times longer than call itself.
For example: 1000 ms - execution of business logic;
and 10ms call time for CORBA and 100ms for SOAP the overall difference will be just 8.2% faster with CORBA. Who cares that CORBA call is 10 times faster.
As for integration difficulties - I know somebody to blame for inability to develop properly...

I don't agree with this at all. We had a scenario where we wanted to call WebLogic workflows from an ASP .Net client. We had 3 different approachs: a CORBA based bridge product, a different .Net remoting based bridge product and web services. The bridge products took quite a bit of time to integrate and code whereas the web service was generated instantly with a right-click. We ran extensive stress tests on the three methods and the difference in time was negligible.

SOAP RPC is just complete bloatware for most uses.
I think to be fair, all these SOAP performance benchmarks really just deal with serilization, transport, and deserilization costs. The actual cost of the service execution is not included. CORBA & ICE are superior what comes to performance in the measured areas. They are in fact vastly superior to the extent that I would not ignore it.
So, if you are doing RPC in controlled space, there is little/no reason to use SOAP at all. This especially if performance is of any concern.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.