Eugene Kuznetsov

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


Related Topics: Virtualization Magazine, XML Magazine

Virtualization: Article

XML-Aware Networking

XML-Aware Networking

XML is, among many other things, a data-encoding standard for network protocols. What's known as "XML" in the community or the trade press is actually a large collection of protocols and data-handling systems that use XML-encoded packets or instructions.

SOAP, XML-RPC, UDDI, BXXP, XSLT/XPath, XML DSig, XML Enc, SAML, XSD - despite their disparate purposes and higher-level complexities, the one requirement they share is the need to parse, and process, XML. If XML is a new protocol, just as HTTP was in the Web's infancy, it's not hard to see that a new breed of intelligent network infrastructure can be created and harnessed to overcome XML's own growing pains. XML network equipment hardware is already being sold.

Keeping that in mind, this article provides an overview of some of the types of XML-aware network devices on the horizon and how they may be able to alleviate some of the barriers to XML's success.

Existing HTTP-Aware Network Equipment
The rapid growth of the Web in its early days quickly meant that performance and reliability needs escalated well past those offered by a single server. Server load balancing (SLB) provided the ability to have a group of servers appear as a single Web server to users. This virtualization of Web servers was done initially by special software deployed on the Web servers themselves. But SLB functionality moved very quickly from software into content-aware network hardware, both appliance- and switch-grade products delivered by companies such as F5 Networks, ArrowPoint Communications, and Alteon WebSystems. Hardware load balancers provided the performance and reliability demanded by the ever-expanding Web server farms running the Internet's largest sites.

In a typical installation, incoming page requests were load balanced among dozens of individual Web servers, and the load-balancing algorithms themselves quickly became more complex: URL switching, cookie redirection, and SSL ID tracking are a few examples. Web application developers became aware of load-balancer functionality, and sometimes the infrastructure's capability influenced application design so as to make the use of an SLB possible or more beneficial.

Both content switching and content caching grew up with the Web, evolving their features in response to the new applications and protocols, and enabling the tremendous growth of the Web. Content caching, load balancing, and other elements of the HTTP-aware network infrastructure helped overcome the early Web's performance, reliability, and security problems, and enabled it to be used for the kinds of applications (e.g., large news portals or online stores) that could fuel its growth even further. While SOAP and XML-RPC are built on top of HTTP and can therefore flow through these old load balancers and accelerators, the content-aware network equipment designed for Web traffic doesn't know anything about XML-encoded data or new protocols accompanying it. To be really useful for next-generation protocols, network devices must be "XML-aware," or capable of looking further up the network stack, past TCP, SSL, HTTP, and parsing the XML messages themselves.

XML-Aware Network Equipment
XML redirectors offer basic routing functionality for XML and are also sometimes referred to as XML switches or XML routers. Because they're the simplest kind of XML-aware "box," they were the first ones to become commercially available (Intel offered the now discontinued NetStructure XML redirector two years ago). Such a device would be placed between the servers and the incoming XML traffic and can be very useful in redirecting XML messages between different servers based on their content. For example, all purchase orders over $50,000 could be redirected to the fast application server, while all others could be sent to the slower server. In addition to handling this kind of trivial QoS (quality of service) issue, the same device could send messages in a particular XML vocabulary to the server capable of processing them, or it could send separate XML-RPC and SOAP messages. The routing rules are specified using either proprietary pattern-matching languages or a limited subset of XPath.

XML accelerators are network devices that aim to speed up either the flow or the processing of XML messages. XML processing performance can be a barrier to adoption of XML technologies for business-critical applications. An XML accelerator has the ability to offload one or more resource-intensive XML processing functions onto purpose-built hardware. For example, bottlenecks associated with XML parsing and XSLT are a frequent and well-known problem. XML accelerators can perform XSLT transformations outside the application and greatly improve transaction throughput and reduce page load times. Using standards such as xml-stylesheet processing instructions can make it very easy to drop an accelerator into an existing environment.

Other types of XML processing can also be performed "in the network," with an XML accelerator taking over the bottlenecked functionality from the application server. In order to take over processing, the accelerator can't implement just a subset of a specification, of course; it must be fully conformant to the standard.

To be considered an accelerator, the device should offer much better performance than a general-purpose server. In fact, the best accelerators will be quite unlike general-purpose servers: custom-built gear lacking hard disks, keyboard, or screens, and controlled through existing network management systems and interfaces. This is similar to SSL accelerators or Web caches, which have been speeding up Web sites and e-commerce applications for years by providing a single-purpose offload function. Since SOAP and other Web services protocols are all XML-based, their performance is intrinsically dependent on XML performance. Expect the XML acceleration space to get quite crowded with a number of very sophisticated devices offering better XSLT performance, high-speed schema validation, XML parsing, or other functions.

XML firewalls are true to their name and play the same role for XML traffic that traditional IP firewalls do for the rest of the enterprise network. Security is quickly becoming a hot topic with respect to XML Web services, and with good reason: if there's one issue that can stop or roll back the advance of XML messaging systems, it's security. An XML (or SOAP) firewall intercepts incoming and outgoing XML messages and has one or more of the following security functions:

  • Performs XML well-formedness checks to screen out invalid XML
  • Provides XML denial-of-service attack protection
  • Validates against standard (e.g., SOAP) or custom user-specified XML schemas or DTDs
  • Verifies XML signatures
  • Encrypts sensitive message fields as necessary
It would take only one well-publicized security fiasco in a Web services app at a Fortune 500 company to stall the Web services efforts at the other 499. An XML firewall is on the wish list of many network administrators because it picks up where the existing firewall leaves off, and offers a measure of XML security and access control at the network level. Without it, his or her only options are either to attempt to block all XML network traffic or rely on the growing number of XML-enabled applications to be the sole layer of security. As a result, even today, deployment of externally facing Web services applications is often held back by concerns of the corporate network security group about opening up port 80 to incoming SOAP traffic, or just the very notion of offering RPC access to the back end of the enterprise's system.

Technical Challenges
Designing and building a truly useful XML-aware network device is an extremely difficult technical undertaking. Because enterprise network equipment is expected to function at wirespeed (at least Fast Ethernet or 100 megabits per second), the same is required of the XML processing core embedded in the device. Smart decisions also need to be made about what kind of XML functionality can be put into the network without introducing additional complexity into the overall architecture.

For example, manual setup of transformation rules can be cumbersome if not designed carefully. The complexity of configuration can be greatly eased by offering integration with XML development tools. A good XML network device should integrate seamlessly with application software, preserving XML standards compliance while delivering the kind of performance expected of network devices.

XML Network Services
It's important to note that the network infrastructure is composed of both network equipment and network services. Although XML-aware network equipment is much further along than network services, we can look forward to some changes in how complex applications are built. Looking again to the HTTP-aware network, during the Web's early growth it became clear that performance and reliability needs of the largest Web sites were well past those offered by one server cluster. Flash crowds spurred by major events could overwhelm any single network or server group, and the Internet's growing global reach meant even longer waits and growing bandwidth costs. Distributed edge caches moved content closer to users, reducing latency, load on origin servers, and ISP bandwidth costs all at once. Content Distribution Network (CDN) is a network service employing thousands of caching servers located at ISPs across the globe and first offered by startups: Akamai, Digital Island, and several others.

Similar kinds of "overlay" networks are now being created to offer guaranteed delivery of business documents or transactions through the Internet. Such a service is designed to allow the customer to send a purchase order "into the network cloud" and be assured that it will be delivered to its destination despite any failed network links, security challenges, or other disruptions.

Online machine-readable directories for XML Web services are another obvious network service, and it's no accident that some of the biggest existing network service providers are involved in UDDI and similar initiatives. The hope is that UDDI or a similar directory initiative can become a next-generation domain name system of sorts for Web services endpoints. Of course, just because a resource is publicly listed doesn't mean that it should be accessible to all or without charge. In the security and payment area, innovative startups are creating automated access brokering services based on signed cryptographic assertions, often using SAML, which could enable both pay-per-use XML Web services and new business models for existing content providers.

These are merely examples of the kinds of XML-aware network services an XML developer may be developing for in a year or so.

*  *  *

I've attempted to offer a view of XML messaging and Web services from a different perspective - not from the "top down" point of view of an application, but from the "bottom up" perspective of the network. These two points of view are always different enough to be interesting, and are sometimes even in conflict with each other. Yet, armed with the realization that XML Web services aren't just about applications, they're also about the network, you can look to the Web's early days for the role HTTP-aware network equipment and services played in overcoming the obstacles to its success.

While it may be too early to tell what kind of new "xml-aware" network gear or services will be most successful, XML developers should expect that the network infrastructure a year from now will have the next level of intelligence, with purpose-built "XML-aware" hardware for XML acceleration and security.

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 XML.gov 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 (4) View Comments

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.


Most Recent Comments
Marcelo 04/08/03 09:51:00 AM EDT

Could you please, what does it mean: XML-aware?

I will be thankful.

Marcelo R. Braga.

John Evdemon 08/22/02 06:56:00 PM EDT

Hey guys - I though you'd be interested in hearing about an article in development from Sarvega. Sarvega develops XML/SOAP-enabled network switching products and will be sharing some of their larger customer case studies with us.

Its interesting to see that the big guys (namely Cisco and 3Com) are also moving in this direction.

Gary Johnson 08/20/02 11:57:00 AM EDT

I think issues around "XML Acceleration" as the author puts it are more complex that the way it is described in the article. First, for large XML documents the network issues likely will overshadow any performance improvements in the "Accelerator". Try posting a 100K file to a web server! Second, the article is biased towards presenting pages (mentions page load time)and for the web applications are (1) Using XML/XSLT and (2) Need high throughput it does make some sense (if network issues do not exist!) - but it will be useful to understand that other than top 2-3 sites where else will this be useful?

XML Firewall discussion is more balanced but without major Web Services adoption this is still a "nice concept". Like to see some reality thrown in here too!

Alex Chiesi 08/08/02 08:44:00 PM EDT

I've been turned off by XML because of crappy performance and the time it takes to edit stylesheets to get them to run more quickly. If processing XML in hardware gets me around bottlenecks, I say bring it on.