Look in the network closet in any good-sized company today and you’ll find a wide assortment of network gear: firewalls, switches, gateways, routers, hubs, bridges, the list goes on and on. Each of these devices essentially either directs or secures the packets that form the automobiles on the streets and freeways of today’s networks. All data networks -- including the mother of all data networks, the Internet -- are built from these packet-directing and packet-securing devices. All this equipment works pretty well, as long as they don’t care what is actually inside the packets. And there’s the rub. The amount of traffic going over the network that is XML formatted -- in particular, Web Services messages -- is set to explode, and all that equipment in the closet is completely unprepared to direct or secure that XML traffic.

To understand why XML traffic is different from other network traffic, it is important to look under the covers of just what network traffic is, and how network devices work. The key to understanding network traffic is the Open System Interconnection, or OSI model for networking. The OSI model describes network traffic as a stack of layers, each one more abstract than the layer below. The diagram below illustrates the seven basic levels of the OSI model -- physical, link, network, transport, session, presentation, and application:

All the network gear mentioned above works at the five lower levels of the OSI stack. Vendors such as Cisco, Nortel, 3Com, Linksys, Intel, and dozens of others have produced hardware network appliances that direct and secure packets, and streamline and improve the efficiency of handling network traffic. All of this network gear -- gateways, routers, firewalls, etc. -- have melded together into a broad category called "network intermediaries" in that they facilitate communications between systems, but aren't the end systems themselves. However, for all these network intermediaries do, they are still stuck in the lower five levels of the OSI stack -- because they don’t deal with content.

Making the Case for the XML Proxy
The first six levels of the stack basically handle the nuts and bolts of network communication, while Web traffic (HTTP), email (SMTP), and other Internet protocols are part of the uppermost, application layer. As far as a firewall or router or gateway is concerned, this Internet traffic consists of nothing but applications talking to applications. Where, then, do the emerging XML and Web Services protocols such as SOAP, WSDL, and UDDI operate? These protocols don’t really fit in the OSI stack at all, because they are content-oriented, rather than network protocol-oriented specifications. So, while the OSI model is a mechanism that provides an understanding of traditional networking products, new XML-aware networking products must transcend the limited OSI model and focus not on the message packet or envelope, but rather the content of the message itself.

This distinction between XML-aware, content-oriented products and network protocol-oriented devices is clearest when looking at firewalls. Most current firewalls work by blocking access to all network traffic, except ones that run on certain TCP ports such as Web traffic (HTTP port 80 and HTTPS port 443) and email traffic (SMTP port 25). However, most XML and Web Services traffic runs over the standard HTTP and HTTPS ports. Unfortunately, today’s TCP/IP-based firewalls can only permit or deny all traffic through these ports. The big problem with this all-or-nothing proposition is that XML/Web Services traffic might be undesirable at the content-level, unlike standard HTTP traffic, because Web Service traffic could theoretically execute any instruction on any computer on a company’s internal network.

Therefore, firewalls must become aware not only of the network ports and IP addresses, but also of the content itself that is traveling across the network. Unfortunately, current firewall, router, proxy, and switch solutions are simply not up to the task. Instead of being simply network and IP-aware, these solutions need to be content-aware. More specifically, they need to be XML-aware. These devices must be able to inspect and understand XML traffic as it flows across the network and perform some sort of activity on the traffic, following the policies set for the purpose.

ZapThink prefers the term XML Proxy to describe the evolving role of XML-aware network intermediaries. XML Proxies consist of either software or hardware applications that monitor network traffic for XML content and perform some kind of activity on that traffic. We distinguish XML Proxies from other types of network intermediaries in that they are XML-aware, while others may be TCP/IP aware or HTTP aware. However, other than the fact that XML Proxies facilitate XML communications and are capable of processing XML documents, the role that XML Proxies fill varies depending on the activity they perform on the XML content.

XML Proxies currently on the market offer a wide-ranging set of functionality for handling corporate-wide XML security, management, routing, transformation, and performance enhancement. Enterprises will implement XML Proxies as a transparent layer over current network traffic (both inside and across the firewall), monitoring and acting on XML data by following established rules.

The ZapThink Take
Today there are many vendors who have recognized the need for XML-aware network intermediaries, and are developing a range of products to meet this need. Being a nascent market, however, the terminology is all over the map: network appliance, software XML firewall, XML application firewall, XML switch, Web Services gateway, the list seems endless. ZapThink considered this terminology tangle and came up with a recommendation. While the term "XML-aware Intermediaries" is a broadly inclusive and generally accurate assessment of the current products and services on the market, ZapThink believes that "XML Proxy" is a more marketable name, and hence one that can more adequately distinguish the current class of products and solutions on the market today and in the years to come.