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

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.