By Frank Coyle. Date: Dec 30, 2005.

Article Description

Frank Coyle went to Interop this year to see what impact, if any, XML was having on the movers and shakers in the world of networking. Overall, my foray into Interop 2005 gave me new insights into how XML's success is impacting the world of networking and how what occurs at the application level impacts the network in a variety of ways. For some of the challenges associated with XML processing, hardware-based solutions go a long way toward alleviating the pressure on servers to parse, extract and route XML traffic. But the challenges associated with the increased bandwidth have fewer ready made solutions and when coupled with the explosion of asynchronous XML traffic generated by Ajax styled web applications, create enough challenges to keep network managers from getting a good night's sleep.  

This December, Interop 2005 held its major network interoperability conference at New York City's Jacob Javits Center. I decided to stop by and have a look, interested in seeing what impact, if any, XML was having on the movers and shakers in the world of networking.  

What's in a name?

If the name Interop sounds vaguely familiar to you, it's because both the conference name and conference focus have changed over the past 19 years to keep pace with the ongoing changes in networking and the web. Back in pre-web 1986 Interop began as a workshop sponsored by DARPA and the Internet Activities Board (IAB) to bring TCP/IP designers and implementers together to explore the future of TCP/IP. The workshop quickly expanded into a conference called the TCP/IP Interoperability Conference, where getting networks to talk to each other was the primary focus. In 1994, as the Web began to take shape, the conference morphed to NetWorld+Interop and then as recently as 2005 the NetWorld prefix was dropped and the conference settled in with its current name, Interop.  

Looking at the name changes as indicative of how the networking community viewed its mission, I was curious to see how the players in networking were being influenced by Web Services and Service Oriented Architectures (SOAs), both hot topics in the XML world. A recent research report from ZapThink (http://www.zapthink.com) predicted a growth in XML traffic on corporate networks from 15% in 2004 to just under 48% by 2008. With these numbers in mind, I decided to brave the windy canyons of the Big Apple and see for myself how XML and network managers were getting along.  

After just a short time at Interop it became clear that XML was a significant factor for network planners. Organized around major tracks, the conference included tracks you might expect - - Security, Voice over IP (VoIP) and Wireless and Mobility. But the track that got my attention was the one entitled Application Networks.  

The Application Network

Application Network is a new term that reflects the reality that networks need to be closely integrated with applications to insure that the enterprise effectively bridges the gap between infrastructure, devices, applications and users. This converged network, the application network, is seen as the source of a new generation of solutions - and at the core is XML.  

To trace the evolution of application network, we can look back to XML's emergence around 1995 as a meta-language for defining domain specific vocabularies. Soon after XML's arrival, XML-RPC was launched as a way to eliminate the infrastructure constraints imposed by code centric distributed computing approaches such as CORBA and DCOM. Around 2001, XML's success in enabling data distribution across networks led to the rise of web services, centered around a host of XML technologies that included SOAP envelopes and protocols for platform-independent distributed computing, WSDL for describing web services and UDDI for publishing and lookup. With the web services infrastructure in place, we then began to see architectural solutions structured around distributed XML interactions and leading to what has become known as SOA or service oriented architectures.  

Figure 1. Conventional vs. Service Oriented Architecture (SOA)  

As illustrated in Figure 1, SOA represents a major change in the structure of web based applications. Conventional web-based client server applications are organized in tiers - a web tier to manage browser interaction, an application tier to hold the business logic and a data tier for data management. In the new world of SOA, application functionality is distributed across a variety of platforms delivering data and services based on XML messaging. These XML messages, typically traveling in XML SOAP envelopes with services defined by XML-based WSDL descriptors.  

With service-oriented architectures delivering pieces of an application from across the network, new applications are emerging that integrate content from different network locations into a central portal. For application builders this means that the application and the network are now more closely tied to each other. Developers must understand how their technology impacts the network and network planners must more closely understand their applications and how they affect network performance. One of mantras heard over and over at Interop was that responsive, available, accessible applications delivered efficiently to end users are the only measures by which IT should be judged.  

Three XML Network Challenges

While XML network traffic opens up new possibilities for connectivity, from a network perspective, XML creates a new set of issues and challenges. These include, first, the additional processing power needed to handle the XML messages arriving at application servers. When an XML packet is received on the server, it needs to be parsed, queried and routed to appropriate handlers. The net effect is that many companies need to double their infrastructure and dedicate additional resources to application servers. And if security is part of the equation, even more resources need to be dedicated to encryption, decryption and access management.  

The second challenge is how to cope with the additional bandwidth required to move XML across the network. Since XML is text, it requires significantly more bandwidth than leaner binary formats which in turn requires additional capacity.  

A third challenge associated with XML and the network is more subtle and has to do with XML's ability to combine with other technologies to create new ways to doing things. For example, XML in conjunction with JavaScript is being used to increase the responsiveness of web applications. Technologies such as AJAX (Asynchronous JavaScript and XML) are creating a new model of web interaction, which is getting the attention of network managers due to the possibility of greatly increased bandwidth and processing requirements.  

So what's a network manager to do to cope with increasing onslaught of XML traffic? Let's look at each of the challenges in turn and see how the network folks are beginning to cope.  

Accelerators: Easing the XML Processing Burden

When XML arrives at a network server, it typically is packaged in a XML SOAP envelope that includes a SOAP body with the XML payload. Because SOAP supports chaining SOAP servers, decisions have to be made concerning what to do with the incoming XML. Options include extracting data, modification of all or part of the message, encryption/decryption, executing XSLT-based transforms and forwarding messages to another server. All of this takes time and processing power which impacts server throughput.  

Because XML and service-oriented architectures make content understandable, there is a demand to do much of this processing as possible in hardware, particularly in information-heavy enterprises that need to link many disparate applications and experience spikes in application usage. Responding to this demand are companies building XML accelerators, dedicated hardware to handle the onslaught of XML traffic generated by services-based applications.  

For example, in June 2005, Cisco announced its Application-Oriented Networking (AON) product line, which is based around its Catalyst 6500 switch that parses and does encryption on XML traffic before it ever gets to the server. The basic idea is to use hardware based parsers to look inside packets, figure out the nature of the traffic and then do application specific routing without taxing the web or application server.  

Among other XML hardware acquisitions in 2005, Intel purchased Sarvega, which makes appliances for handling XML and Web services traffic and in early December, IBM, acquired privately held DataPower, one of a handful of startups that is shaping the market for XML appliances. From what I gather, IBM plans to develop a family of SOA appliances based on the DataPower technology, which it's adding to its WebSphere software product line.  

On the exhibit floor, an interesting Irish startup company Dajeil Limited (named after a character in one of Iain Bank's futuristic sci-fi novels), was demonstrating a chip set that sits on a card that plugs into a motherboard slot. The card called the DH15K is designed to help companies manage the bottlenecks and security issues that arise when dealing with high volumes of XML and Web Services traffic. The DH15K is an amazing little card that can offload and accelerate XML parsing, schema validation, XPath expressions and WSS functions simultaneously, freeing up the CPU to do whatever else it needs to do.  

XML and the Bandwidth Challenge

While hardware accelerators can offload the processing burden for an XML server, there's no easy way to use hardware to reduce the size of XML traffic. Strategies for overcoming the size problem include applying standard compression algorithms such as GZIP for reducing the size of the XML as travels across the network. Using GZIP encoding over HTTP transport is an established technique for improving the performance of Web applications. High traffic web sites often use GZIP to make their user's experience faster, and the compression technology is widely used to make files smaller for download and exchange.  

But with straight compression there's no free lunch. If you compress to reduce size you then need to do additional processing to expand the XML back to its original form. 

As an alternatives to compression, binary XML is now under official discussion as part of the newly formed World Wide Web Consortium's XML Binary Characterization Working Group (XBC). In November of 2005, the W3C announced a new working group, the Efficient XML Interchange (EXI) Working Group to examine the feasibility of the Binary XML recommendations from the XBC group. Chartered through December 2007, the EXI group will begin by considering existing solutions and will evaluate each in terms of implementability and performance against the requirements and use cases produced by the XBC Working Group. The challenge will be to accommodate the widely disparate requirements for the stakeholders in XML compression that range from mobile application developers looking to move short snippets of XML across low bandwidth mobile networks to oil and gas explorers dragging sensor arrays across the ocean floor and creating terabytes of XML for transport across networks. How these disparate requirements will be worked out remains to be seen.  

XML and the AJAX Model

One the requirements listed in the original XML specification was that it be simple and capable of combination with other technologies. One technology getting significant attention recently is Ajax or Asynchronous JavaScript and XML, a web development technique for creating interactive, responsive web applications. Technically, Ajax does not require the use of either JavaScript or XML although these two technologies are most commonly associated with the asynchronous nature of Ajax web interactions.  

To understand how Ajax is impacting network planners it's helpful to compare the traditional web client server model with Ajax.  

Figure 2. With AJAX (Asynchronous Javascript and XML) browser server communication is not directly associated with a users web requests.  

As illustrated in Figure 2, with the conventional web, the web browser and server interact in a request response model. A user's browser click results in a request to a server, which in turns delivers a new web page. In the Ajax model, the browser through the use of JavaScript, can initiate communication with the server asynchronously and independently of user input. Google Maps, for example, is a web application designed according to the Ajax model where map segments that surround the current display are fetched independently of user movement. Scroll right across your map and the underlying JavaScript will generate multiple server requests trying to anticipate where you will be looking next.  

While users find GoogleMaps quick and responsive, network planners see a potential barrage of packets heading back to their servers from a single web request. Because the creation of asynchronous communication back to the server has the potential to generate compelling, responsive web applications, it looks to be just a matter of time before more developers latch on to the technique. For organizations that take the idea of application network seriously, expect to see guidelines and constraints on the use of the Ajax related technologies. For organizations that don't understand the increasingly important connection between networks and applications, expect to see servers come crashing down at the hands of their own developers inadvertently generating their own denial of service attacks via Ajax web requests.  

Overall, my foray into Interop 2005 gave me new insights into how XML's success is impacting the world of networking and how what occurs at the application level impacts the network in a variety of ways. For some of the challenges associated with XML processing, hardware-based solutions go a long way toward alleviating the pressure on servers to parse, extract and route XML traffic. But the challenges associated with the increased bandwidth have fewer ready made solutions and when coupled with the explosion of asynchronous XML traffic generated by Ajax styled web applications, create enough challenges to keep network managers from getting a good night's sleep.