What about performance?

The five challenges highlighted in this article reflect trade-offs intrinsic to the distributed, loosely coupled nature of Web services-based SOAs. But skeptics frequently cite another issue — performance — as a particular weakness of the model. This criticism generally has two parts: the distributed nature of SOAs and the overhead of Web services protocols.

Any distributed system performs slower than a self-contained one, simply because the network becomes the limiting factor. And of course, some applications can’t tolerate network-incurred delays. But that axiom isn’t unique to Web services or SOA. The benefits of flexibility and access gained by keeping systems close to the units of work they represent — and connecting those systems to others across an organization or across the Internet — far outweigh the performance hit introduced by the network.

More germane is the relative weight of XML transactions when compared with binary ones. The effort it takes for a system such as a Java application server to serialize and deserialize SOAP calls into internal objects is estimated to be 10 times higher than that required for native approaches such as Remote Method Invocation. This sounds meaningful until you consider the lessons learned from the Web itself. Like HTML, XML is a very wordy approach to describing information. Yet it is precisely that readability and extensibility that compensates for the performance impact, while Moore’s Law — along with specialized devices such as XML accelerators — moves ever closer to canceling out the performance implications across time.

In the end, neither Web services advocates nor critics hold every card. It’s a question of using the right tool for the right job. High-volume transactions will continue to be addressed by proprietary, binary middleware solutions for some time. But applications that require less frequent but much more flexible interactions will be served, increasingly, by Web services.