Eugene Kuznetsov

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

Related Topics: XML Magazine

XML: Article

XML in Unexpected Places

XML in Unexpected Places

It is a welcome sign of XML's success that it increasingly appears in unexpected places and concerns an everbroadening set of people. Those of you who were involved with XML technology in the early days or who bravely pioneered XML in your organizations years ago may be bewildered by this, and wonder whether all of these "other" people really understand what XML is all about. The major change is that for the business people, the question has now irrevocably become "When XML?" not "XML?". Plugging our ears to keep out the din of marketing noise, let's take a quick tour of the unexpected places you'll find XML.

XML in Firewalls
It is quite natural to ask "Huh? What does XML have to do with firewalls?". XML is quickly becoming part of the network security infrastructure for three major reasons. First, XML Web services were designed to bypass the existing firewalls and intrusion detection systems. You may remember early articles about SOAP that promoted it as "firewall- friendly RPC for Windows." The last thing any security professional wants, especially in the aftermath of MSBlaster, is "firewall-friendly" anything for Windows. Detecting that a particular HTTP connection is actually carrying XML/SOAP and ensuring that the SOAP requests are valid requires an XMLaware firewall, leading a number of startup vendors to develop software and hardware products for the job.

Second, there is a larger trend of moving application-level security into network devices, motivated in part by the realization that most security threats today are at the application layer, and keeping up with the constant flow of application patches turns out to be very difficult in practice. By establishing a universal data encoding for application data and some basic security building blocks, XML makes the move to message- level security easier and more attractive. In addition to securing the enterprise perimeter or encrypting individual connections (using SSL or VPN), you can encrypt and tamper-proof individual messages - regardless of whether they are in transit, stored on disk, or transported hop-by-hop in a multiparty business workflow.

The third and final reason for the appearance of XML in firewalls is the need for separation of concerns between network operations, security, and application development groups in large corporations. Applications are usually deployed and managed not by the developers who build them, but by operations people. Even if it were easy to fully secure Web services traffic inside application code, the security group would still need to be able to change access policies, monitor for breaches, and manage the lower portions of the security stack. This usually does not work well because there is no clean separation of security functions from the application business logic, deploying the same policy to many servers is timeconsuming (especially for those used to managing network appliances), and inevitable battles over policy gray areas arise. As a result, moving corporatewide security policy enforcement to a network device managed by the security group is more scalable and provides some additional checks and balances.

In short, SOAP is "firewall friendly," which is a euphemism for the ability to slice through firewalls like a hot knife through butter - and so there's a need to secure it. To secure it intelligently, a firewall or gateway must be XML-aware. This plays into a larger trend of shifting from transport-layer to message-level security. People dynamics, security hygiene, and organizational politics drive separation of concerns and moving this security into dedicated devices. The whole trend is an opportunity to finally create a universal application security layer (see Figure 1).

Personal XML
In a departure from its documentpublishing and invoice-schema roots, XML is also used in IM. The most prominent is probably Jabber and its XMLbased protocol that is now beginning to be adopted for other, non-IM uses. XML, sometimes in its binary-encoded forms, has long been present in cellphones and PDAs, and it is starting to gather momentum as a control and configuration protocol in telephone networks. The day is not far off when all of your personal communications - from Instant Messaging, to PDA, to cellphone and land line - will be unexpectedly controlled by XML!

Government and Defense
XML is also appearing inside government agencies in both the U.S. and the rest of the world. However, the use of XML should not be surprising given that government agencies have been longtime users of SGML. Several of the U.S. initiatives are worth highlighting. As part of the eGov initiative, the XML Working Group has been doing great work in promoting XML and unified schema registries. The ability to publish both electronically and in print from the same source is important to civilian agencies seeking to move online without leaving those reliant on paper behind.

Law enforcement and military agencies are using XML to integrate intelligence data. Future versions of the Land Warrior combat system, which includes wearable computers integrated into soldiers' uniforms, will exchange real-time data with headquarters. The intelligence community already uses XML as a way to tag incoming messages and associate them with particular topics, geographical areas, and events. Incoming information is then immediately routed to the analysts who are most capable of interpreting and making use of that specific data - for example, messages about small arms fire in sector 1-D should go to Lt. Smith in analysis section 3, marked as high priority. U.S. Army Land Warrior and next-generation combat C4I systems will make extensive use of XML for communication between soldiers on the ground and in command centers (see Figure 2).

Increasingly, many counter-terrorism efforts are seen as a giant information systems integration problem. The Homeland Security Department tries to meet the requirement for a unified terrorist watch list (instead of the muchjeered 19 different lists that exist today). It struggles with fundamental data integration ills not unlike those found in the private sector, and the remedy is increasingly to use XML or Web services whenever possible.

XML Routers
The "big ideas" currently being marketed by the top IT companies are on- demand computing, utility computing, and related concepts for flexible IT cost structures. Underneath the marketing, there are some real technology requirements to implement such a vision - reducing the number of servers and applications that have to be managed by virtualizing compute, storage, and network resources. As with intelligence dispatches destined for Lt. Smith, such shared infrastructure relies on the ability to direct transactions to where they should be processed. The idea of routing transactions based on their content is not new, but XML makes it much more practical by providing a common data encoding format and standards for querying content (primarily XPath).

For example, an XML router can be used to direct all POs that are over $50K and destined for the European division to the London data center. The XML router would parse the entire XML document and evaluate an XPath expression against it, "/po[dest='EU'] and /po/details/total/usd > 50000". Application code would be designed to process any type of transaction. Changes in activity due to national holidays or natural disaster could be accommodated by simply changing the routing rule - and redirecting all POs to the U.S. datacenter, thereby shifting server resources "on demand" across the ocean.

Another application of XML routers is intelligent SOAP load balancing where a single SOAP endpoint is exposed as a front end to many SOAP servers. Emerging specifications (such as WS-Routing and WS-Referral) aim to codify ways of specifying and processing SOAP routing headers. Regardless of the application, virtualized processing resources require the ability to have transactions intelligently routed to them, a job for wirespeed XML routers.

Systems and Network Management
The use of XML in networks is not limited to XML-aware actions on application data to route, transform, or filter them. Today, network and systems management is primarily done using a menagerie of technologies: SNMP MIBs, CLI (such as Cisco's commandline interface), product-specific GUIs, syslog logs, and proprietary agent plugins. Of these, product-specific GUIs and CLIs tend to provide the most detailed and up-to-date information, but are the most difficult to integrate into an overall network or security management framework. (When a Fortune 500 company NOC is using screen-scraping Perl scripts to monitor and control their routers and servers, that's probably a sign that some technological shortcomings need to be corrected.) SNMP is widely supported, especially by network equipment, but tends to expose only a fraction of a device's capability. The functionality is further curtailed by security policies that frequently limit SNMP to readonly access. Custom agents that use proprietary wire protocols to converse with the central management server usually provide more functionality than SNMP, but less than the native product UI - they are popular for app server management and single sign-on systems, and less so for network gear. Finally, logs can be captured and filtered to monitor for events of interest such as security events or response time warnings. All of this falls far short of the dream of an enterprise-wide management system, and the challenges should seem eerily familiar to readers involved with EAI and B2B integration projects.

This insight that systems, security, and network management can be viewed as an integration problem is now encouraging the use of XML as a standard way of managing networks and systems. F5 Networks has released its iControl interface, a SOAP API that enables programmatic control of their traffic management devices. DataPower offers a full WS-I BasicProfile-compliant SOAP API for our XML security gateways and XML accelerators. The three leading systems/network management vendors - Computer Associates, Hewlett Packard, and IBM - have been moving to add Web services interfaces to their products as well.

The goal is to make it easier to connect devices to management servers, enable more connections (so that every device is centrally managed), and finally to get richer information from the managed nodes. If yesterday's network management consists of a "grep" on logfiles for an alert, an SNMP call to get the number of sent packets, and a script to generate some CLI commands across a telnet session in response, today XML as the network management protocol allows all of this to happen using the same API with a better user interface. The information is also much richer - rather than the number of packets, you might be able to see the total number and value of transactions. Security policies encoded as WS-Policy or XACML are pushed out to policy enforcement nodes, which apply filters and access control to application traffic (see Figure 3).

To avoid confusion, it's important to note that, unlike XML-aware network devices such as XML firewalls or XML routers, an XML-managed device does not require that its dataplane be XMLaware - even a simple Ethernet switch can be modified to be configurable using XML. It can continue to be unaware of the XML contained in the ethernet packets it's forwarding (see Figure 4).

Finding XML in all of these unexpected places is a great sign for adoption, but can be a little disorienting and saddening for pioneers. For them, it's not unlike the day when the rest of the world discovered the Internet, and it suddenly became something very different from what it was. Seeing the reasons for the emergence of XML outside software systems requires an understanding of the bigger picture and organizational dynamics, such as the need to control company-wide security policy outside application code. Beware of combining all XML projects into one corporate initiative - the presence of XML today is becoming so broad that such a combination may prevent all of them from making progress rather than conserve resources. After all, you wouldn't think of combining all the projects that use ASCII into one? While XML isn't quite as pervasive as ASCII yet, it's certainly starting to appear in some quite unexpected places, just like any other dominant technology.


  • XML.Gov:
  • CIO Council XML Working Group:
  • Schafer, Scott Tyler. "XML Exposes Rich Network Data." InfoWorld.
  • Jabber Technology Overview:
  • Web Services Policy Framework (WSPolicy):
  • 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.