Eugene Kuznetsov

Subscribe to Eugene Kuznetsov: eMailAlertsEmail Alerts
Get Eugene Kuznetsov: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: XML Magazine

XML: Article

The Adoption: Hype Ratio

The Adoption: Hype Ratio

Even today, I'm frequently faced with those who are disappointed at the progress of XML and Web services. My stock answer to skeptical questions about XML adoption is to talk instead about the "Adoption:Hype" ratio and agree that its value is at or near zero. The many successful projects cannot possibly match the infinite hype associated with the technologies.

Often, the enthusiasm of even the most technical groups outpaces what can actually be achieved in production given the readiness of the software packages, required standards, corporate politics, and developer tools. What is needed is a pragmatic approach to XML and Web services, one that reconciles both that real mission-critical projects are being put into production today and that some parts of the industry are not yet ready.

Reasoning About Performance
In an ideal world, networks are infinitely fast, bandwidth is free, and there is no overhead to using XML messages or SOAP calls to integrate applications. The real-world constraints can be easily analyzed with some simple rules. First, calculate both the total network bandwidth consumption and processing speed of a given transaction. Network overhead in megabits can be approximated by: FILESIZE + HEADERSIZE (KB) * 0.008. Each transaction will have a fixed overhead due to various headers (e.g., IP, HTTP, SOAP), usually insignificant if HEADERSIZE is much smaller than FILESIZE. For example, let's take a simple dynamic XML Web site. If your new Web site uses 50KB XML input files, transforms them using XSLT, and produces 100KB of HTML as output, assuming HTTP overhead of 0.50KB per transaction, each transaction will consume approximately 1.2 megabits. Therefore, the maximum possible TPS = (100MBps/1.2MB) on a fast ethernet network will be somewhere around 83 transactions per second (TPS). (Note: This makes several simplifying assumptions, including a half-duplex network that has no other traffic.)

Second, calculate the effect of XML processing speed. With common software engines, XML parsing throughput ranges between 4 and 40MBps, and XSLT is between 1 and 10MBps. Schema validation, complexity of XPath/XSLT processing, and the greater node-per-byte ratio of document content all serve to reduce the throughput. Because the ranges are wide and often depend on both hardware and software configuration, it's best to use a standard tool (such as XSLTMark or SOAPMark, see Table 1) to find out how long a specific application processing step takes. For this example, let's assume a total throughput of about 10MBps or 120ms per complete transaction. This would mean a best-case maximum of only 8.3 TPS per CPU, much lower than the wirespeed limit of 83 TPS calculated earlier. At least 10 CPUs scaling in an ideal fashion would be required to reach the 83 TPS limit. Similarly, 1 GB/sec speed would require 100 CPUs, unless special XML accelerators are employed.

This kind of first-order reasoning about throughput is very helpful when discussing business requirements for XML network applications. You'll find it just as helpful in sanity-checking figures from the first performance lab tests as in applying common sense to unreasonably high TPS requirements handed down from above.

Real-World Security
Another area of considerable practical difficulty is security, especially when it comes to Web services. While the security issue is finally receiving some much-needed attention, there is not enough clarity to be useful in practice. There is a misconception that no security is needed inside the firewall, and any externally exposed Web service must necessarily use the complete set of security specifications. Neither is true in practice: the enterprise security perimeter is increasingly "dissolving," to use a term originated by @stake (a prominent security consulting firm), and there are ways to deploy secure XML Web services today, without waiting for all the specifications to become fully baked.

There's a pragmatic approach that allows applications to be deployed today and to migrate to the latest specifications step-by-step. It's motivated by the belief that internal threats are no less dangerous than external ones, and that today's internal Web services project may need to be made available to external partners in a rush tomorrow. The first step is securing the transport layer using existing encryption technology. Although IPSec-based VPNs are the technology traditionally associated with securing extranets, SSL has proven easier to deploy and provides a more flexible security model. It is easily deployed between servers that are both inches apart and thousands of miles apart. Primitive and oft-cumbersome but secure access control can be implemented by using SSL client certificates. Other examples of pragmatically adapting existing security technologies or concepts to the world of Web services security are secure transaction logging, PKI integration, and CRL.

Another simple but essential technique is hiding the internals from the "outside," at both the network and application layers. For networks, this is done using familiar NAT (Network Address Translation) and/or proxying. At the next level up the stack, the HTTP protocol layer, URL rewriting serves to obscure endpoints and their structure. Finally, at the XML application layer, transforming all the XML messages (or requests and responses) provides what can be thought of as "XML Address Translation": mapping between the private internal data layout and the external one. This kind of application-layer protection is easily implemented today using XSLT, one of the most mature XML technologies.

The fluid state of many Web services security specifications doesn't have to be an impediment to using some of them today. XML Signature and XML Encryption have reached REC status in W3C and can be deployed without risk of future changes. However, incompatibilities between different implementations are still frequent, and practical experience suggests that careful interoperability testing should be conducted on all software and/or hardware used for XML crypto processing. For newer specifications, choose XML security packages or solutions that can be easily adapted to changes in specifications. The great thing about XML security standards is that they uniformly use XML as the data-encoding format, so their implementations should possess flexibility comparable to that of all other XML-handling software. The assumption should be that all the standards will experience minor changes in the next six months - the software should be designed with this in mind to avoid quick obsolescence.

Although standards bodies are only now beginning to put minimum performance requirements into specifications, an important practical consideration is the performance impact of any added security. Securing XML Web services is largely an XML-processing problem, so performance is again an important issue in practice (see Figure 1). For widely available XML engines, a simple rule of thumb is that schema validation and parsing is 3-4 times more time-consuming that parsing alone. Even the performance of XML Encryption and XML Digital Signature turns out to be dominated by XML processing operations.

One estimate puts the processing overhead of a fully secured XML transaction at 10 times that of a one without any security features. So it's not surprising that there are Web services deployments today that knowingly disable essential security functions, such as schema validation and message transformation, to get the required performance. This behavior causes much consternation among security analysts, but is the kind of security-or-performance choice that's familiar to those actually implementing XML applications. The reality is that much like overly complex home burglar alarms and metal detectors with lengthy lines, any Web services security function that slows down transactions is often left turned-off. The approaches for performance planning mentioned above can be used for estimating the impact of security processing as well. Remember that well-encrypted data cannot be compressed, so compression will be less effective for reducing the network impact of transactions with a lot of encrypted data.

It's also important not to forget about the deployment and operational aspects of adding security capability. Today, XML Web services security is an issue that sits between two separate organizations, the applications group and the security group. This can lead to great difficulty in getting apps into production, and is again a practical (although not at all technical) issue that's important to be aware of.

Proof Is in the Practice
This article attempted a brief overview of large-scale XML and Web services deployment from a practical perspective. There is much more to be said about Web services deployment and how the model of loosely coupled entities can solve some old practical problems and introduce brand new ones. The important thing is that with the application of common sense to both sides of the Adoption:Hype ratio, XML technology will continue its upward trend.

More Stories By Eugene Kuznetsov

Eugene Kuznetsov is noted as the pioneer in the SOA appliance category and a recognized leader within the XML, Web services and SOA industries. With an innovative vision for the next generation of intelligent network equipment (XML-aware networking or XAN) to secure, rationalize, accelerate and integrate applications, Mr. Kuznetsov was the founder of DataPower in 1999 where he served for three years as president and CTO then as chairman and CTO until IBM's acquisition of DataPower in October 2005. In recognition of his XAN vision and leadership, Mr. Kuznetsov was named one of the "Top 25 Most Influential CTOs" for 2005. Prior to DataPower Mr. Kuznetsov consulted for numerous companies including Microsoft on a variety of projects in the areas of memory management, power electronics, JIT compilers, optimized execution engines and application integration. Eugene is a well-regarded speaker appearing at numerous conferences and events including Digital ID World, JAVAOne, NetSec, NATO C3 Agency, HPWorld, CIO Council Working Group, Web Services DevCon, MITRE XML Day, NECINA, Web Services Edge, Gartner's Application Integration and Web Services Summit, the IT Security & Privacy Conference, and ITTC 2004. Mr. Kuznetsov holds a BSEE from MIT.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.