While Web services may promise superior integration, it also presents a significant challenge when it comes to speed and performance.
Take for example a recent Web services conference. A group of developers were asked whether they encountered performance issues working with Web services.
All attendees in the room raised their hands.
There are three approaches to Web services and SOA performance optimization, according to Ron Schmelzer, senior analyst at Waltham, Mass.-based ZapThink LLC. Companies can use specialized hardware accelerators, an optimized software and compression approach, or use binary XML to replace the unparsed, text-based XML format.
"XML is traditionally a text-based, meta data-loaded document format, which makes it incredibly inefficient from a network, processor and storage performance perspective," Schmelzer said.
The network and processing overhead associated with XML is one of the major hindrances to Web services performance. As a result, there has been a push in the industry toward standardizing on a binary encoding scheme for XML.
Last month, the W3C Technical Architecture Group (TAG) created an exploratory committee to examine the ramifications of a binary XML specification. Opponents are worried about the potentially negative effects a binary XML standard might have on interoperability.
"Typical Web services have large payloads," Sameer Tyagi, senior staff engineer at Sun Microsystems, said during
The XML performance problem can be addressed at the hardware and network levels, according to Tyagi. Companies can vertically scale their application by adding more central processing units, memory and storage, or horizontally scale it through techniques such as clustering (primarily for stateless applications).
Additionally, developers can distribute XML processing by using appliances and accelerators in the presentation and application layers of the network, such as those offered by DataPower and Reactivity.
XML-aware switching products, such as those offered by Cisco appliances, get closer to the network layer. Last month, Cisco reportedly discussed plans to launch a new device that would improve the performance and security of exchanging XML messages, positioning the company for growth in the Web services arena.
However, throwing more hardware at the performance problem is only part of the solution
There are activities that can be done early in the development lifecycle, such as modeling for performance and capacity, according to Tyagi. By clearly identifying business and functional requirements, and designing iteratively, performance issues can be identified earlier, thereby mitigating risk.
Miko Matsumura, vice president of marketing at Cupertino, Calif.-based Infravio, said he thinks that although there's sometimes a tradeoff between performance and interoperability, good application design can maximize both.
To effectively measure performance, you need to be able to monitor it. Performance metrics can be captured by intercepting SOAP messages, Tyagi said. Architecturally, this could be done using either a standalone, proxy-based approach, or by using using container-based filters.
Once these metrics have been obtained, a management tool can be used to correlate the performance metrics to service level agreements. Tyagi emphasized the need for tools and consoles to be able to manage this data in useful ways.
"The underlying platform you use will have a big influence on performance," Tyagi said. "A lot of performance-related stuff is being handled at the hardware layer."
Faced with a choice of "buying vs. building," Tyagi advised that it's probably cheaper to buy.
"There are lots of vendors out there for Web services performance and management," he said.