Web Services' Minority Report

The next time the CTO speaks about Service-Oriented Architectures (SOAs), remember this: XML, the technology underlying today's SOAs, consumes 30 to 50 times more bandwidth than comparable protocols, can increase storage requirements tenfold, and may run a fraction of the speed of traditional interapplication processes. So just how are you going to realize the CTO's vision of an SOA without killing the network?

If you're lucky, you won't have to--at least not yet. Standards are still developing, products are still being introduced, and the strategies of major networking infrastructure players such as Cisco Systems and Nortel Networks are still unclear. What is clear is that the networking and security implications for deploying a full-blown SOA based on XML and Web services are enormous. At every facet of the enterprise, network architects need to rethink the impact that such a move will have on their infrastructure.

That's because rolling out an SOA means capital costs, integration work, and planning, not just in terms of the software architecture, but the underlying physical network. Encompassing XML in any large-scale project will require capital expenditures in terms of accelerators, specialized firewalls, and new types of routers--all at $20,000 to $80,000 a pop. Add to that the risk of Application-layer attacks that interorganizational SOAs create, and network architects have a handful to deal with.

But while you can bide your time now, XML and Web services will be in your future. The benefits of the technology are too widespread and too compelling to ignore. Web services let companies easily couple disparate computing systems, enabling them to streamline business processes among departments and between organizations.

It's not just the face of applications that XML will change, either. The protocol's self-descriptive capabilities will also transform network management. Today, the IETF is hammering out the details of an XML-based network management specification that will likely supersede SNMP, and infrastructure vendors have already added XML-based interfaces to their products (see "Service Management Saves the Enterprise," December 2004).When the time comes to deploy your XML network, begin by assessing the networking architectures in the market. But be warned--it's easy to get confused. XML intelligence is cropping up throughout the network. Aside from XML software and standalone XML appliances, vendors are incorporating XML technology into general-purpose networking devices. Other networking devices are also adding XML-aware packet filtering capabilities, giving them rudimentary XML intelligence.

You can avoid these headaches by focusing on the specific XML functions being treated. There are only three main choices here: acceleration, security, and routing. Identify the right type of XML appliance by examining the OS and system pricing. Only then will you be ready to drill down into the speeds and feeds to learn about the architecture that's right for you.

THE FUTURE APPLICATION

To some extent, the XML appliance vendors are part of a larger drive aimed at optimizing networked application performance. In this view, traditional infrastructure suppliers, server vendors, and XML appliance vendors are competing with one another to provide the infrastructure that will drive the new data center.

It's no secret that IT is going through a radical restructuring of the data center. Instead of application-specific servers, network architects are organizing data centers around a service model where computer network and storage resources can be allocated on the fly (see "The Golden Data Center," June 2004).The question is who will provide the underlying equipment that will sit at the heart of this rejuvenated data center. Traditional infrastructure vendors such as Nortel and F5 Networks are adapting their load balancers to form the hub of this new data center. These boxes sit in front of a server pool and use rudimentary Application-layer awareness to direct incoming requests to the proper servers. At the same time, they off-load application processing from the servers, taking on tasks such as initiating and maintaining TCP, SSL/TLS, and IPSec connections. A similar approach is being taken by Application Front End (AFE) vendors such as Expand Networks, NetScaler, and Redline Networks.

Meanwhile, server vendors such as Sun Microsystems and IBM are joining the fray. Sun introduced the Sun Secure Application Switch N2000 Series, which provides application switching, chip-level embedded security, and dynamic resource virtualization, eliminating the need for load balancers, SSL accelerators, and bandwidth management appliances.

IBM's strategy is different. It aims to pack the data center into its blade server, significantly reducing maintenance, sparing, and upgrade costs. IBM's eServer BladeCenter can be equipped with Nortel's Layer 2-7 GbE Switch module to make basic application switching decisions on incoming traffic. More advanced XML switching can be achieved by running XML acceleration software from Sarvega on one of its blades.

THE CRIME

Ultimately, neither the infrastructure nor the server vendors' solutions alone can provide the Application-layer smarts needed to address the fundamental networking problems created by Web services.Web services carry an inordinate amount of overhead because XML documents are text-based, not binary. They consume 30 to 50 times more network bandwidth than binary-based interapplication communications techniques. Compression helps lower networking requirements, but at the expense of additional processing on both the receiving and sending devices.

The World Wide Web Consortium (W3C) might solve that part of the equation. The organization's XML Binary Characterization Working Group is working on ways to encode XML documents in binary form, not text, to conserve network bandwidth. Last November, the standards body advanced to Proposed Recommendations three technical reports aimed at optimizing the transfer of binary data (such as images) within XML messages. Those reports were titled "XML-binary Optimized Packaging (XOP)," "SOAP Message Transmission Optimization Mechanism," and "Resource Representation SOAP Header Block."

Unlike regular XML documents, binary XML documents can be readily processed and consumed by endpoints without additional decompression and validation. What's more, the entire document doesn't need to be parsed, enabling XML endpoints to consume only the necessary parts of the document. As a result, binary XML promises to improve the speed at which endpoints can process XML documents, all while reducing storage requirements. The networking requirements are also lowered because binary XML compresses, validates, and optimizes documents for processing during the encoding and decoding phases.

The catch is that every networking device inspecting the XML payload must implement binary XML. Such a network overhaul may not be in the cards for many organizations, particularly in the near term. Industry implementation of the standards is still nominal, with only three vendors claiming to implement binary XML, and one of those, Sarvega, implementing its own version called XML EventStream.

XML APPLIANCES: A MINORITY REPORT?Despite its advantages, binary XML can't solve XML's other performance and networking problems, such as security threats, transformation bottlenecks, and content-level routing requirements. To address those XML-specific issues, network architects will need purpose-built solutions. Several start-ups providing these include Actional, DataPower Technology, Conformative Systems, Sarvega, Forum Systems, Reactivity, Vordel, and Layer 7 Technologies.

These products come in three types: software, appliance, or custom ASIC. The least expensive are the software-only solutions provided by Actional, Vordel, Forum, Layer 7, and Sarvega. Next up are the network appliances from Actional, Forum, Vordel, and Layer 7 that come as prepackaged Linux or Windows servers. Supplying a prepackaged Linux or Windows server may reduce costs, but potentially at the sake of performance. Security may also be an issue. Unless the holes in those OSs are patched properly, network architects could find themselves with an even bigger problem.

DataPower and Conformative took the third route, developing custom ASICs to improve processing. According to John Derrick, CEO of Conformative, when a document comes in attached to a Web service, the company's CSXi Server Appliance parses and divides the document into pieces, called doclets. Each doclet is independently processed in parallel, giving the CSXi "50 times improvement" over other XML appliances.

Such dramatic performance claims are the norm in the accelerator industry. Sarvega makes similar claims, but without an ASIC. Girish Juneja, one of Sarvega's founders and senior vice president of product management, contends that ASIC development doesn't necessarily yield higher performance than standard processors if the underlying software is properly designed. The company claims to yield over 5,000 transactions per second with off-the-shelf hardware and its proprietary OS.

FIREPOWER The most well-known of the XML appliances--and the ones that have been around the longest--are those that accelerate the Extensible Stylesheet Language Transformations (XSLT) standard. Every vendor, except for Layer 7, runs XSLT, and most also offer other application server offload functions, such as compression and SSL and TCP offloading.

With their ability to offload SSL and TCP processing, the acceleration solutions offer some of the core functions that the modified load balancers and Front-End Processors (FEPs) provide. In XML-centric environments, XML appliances may even replace FEPs, though it's more likely that they'll complement the equipment. The FEPs or load balancers can inspect incoming traffic, identify the XML documents that require additional processing, then forward them over to the acceleration engines.

In the near term, the need for acceleration engines remains questionable. While nobody doubts that XML processes consume CPU cycles, it's far from clear whether any entity other than a large data center will have the volume of XML traffic needed to justify the cost of an XML accelerator. "If you have 5Mbits/sec of XML traffic or more, then, yes, an accelerator would make sense," says Axel Kloth, founder and CTO of Parimics, a start-up making high-performance, real-time image processing and analysis chipsets. Kloth explored and then rejected the idea of using an XML acceleration engine.

Over the long term, acceleration engines are likely to go the way of SSL accelerators and be incorporated into networking equipment. DataPower says its XG4 ASIC can be licensed and built into just about any other networking product. Unfortunately, no customers were available for citation at press time. Sarvega's XML Speedway software runs on a blade and can be slotted into IBM's eServer BladeCenter or Egenera's BladeFrame platform. Other vendors, such as Tarari, offer XML content processors that can be licensed by OEMs.

SECURITY As Web services evolve, IT must introduce a protection layer to defend against Application-layer threats that are harder or impossible to detect with Deep Packet Inspection (DPI) engines.

At a minimum, the security engine must be able to validate the schema. All vendors claim to provide this function, but simple schema validation isn't enough. The process should protect against more sophisticated Application-layer attacks, such as SQL injection and code injection, as well as XML-specific threats. These include XML coercive parsing, where XML documents are specially constructed to be difficult to parse, consuming the resources of the machine; and jumbo payloads, in which very large XML messages--potentially hundreds of megabytes long--exhaust memory and CPU resources on the target system. Several vendors, including DataPower, claim to defend against these sort of attacks.

Given that XML is typically a clear text protocol that can be easily snooped, encryption is also needed. SSL encryption isn't enough because multiple devices need to check the contents of the Web service. With SSL, that would mean decrypting the session at each device and then re-encrypting it once more, increasing the amount of processing at each device and introducing a potential security weakness.

What's needed is a Simple Object Access Protocol (SOAP)-specific encryption layer that will encrypt only those sensitive portions of the SOAP message. The WS-Security protocol provides that layer, enhancing SOAP messaging to protect the message's integrity. It uses the XML Encryption standard to encrypt sensitive parts of the XML payload, then the XML Signature standard to digitally sign the document or elements in the document.

Managing these security appliances are special security servers, such as Vordel's VordelDirector, Layer 7's SecureSpan Manager, or Reactivity's Reactivity Manager. Security servers set policies that XML security appliances enforce on the network. Additional security can be achieved by proxying the client-side application. Layer 7's SecureSpan Bridge is a Web services proxy that insulates the client applications from the associated Web services. The SecureSpan Bridge sits in the network, where it automatically negotiates policy-specific security, routing, and transaction preferences needed for critical applications to traverse Layer 7's SecureSpan Gateway, which also sits in the network. Client applications query the SecureSpan Bridge, which applies the necessary headers, protocols, or transformations required by the company's business policies. Network architects can define and modify those policies using Layer 7's management console, SecureSpan Manager, which then pushes them out to the SecureSpan Bridge in real time.Reactivity extends this model a step further. Network architects establish security policies at the Reactivity Manager. These are then pushed out to the Reactivity Gateway for enforcement at the network perimeter, as well as to the Reactivity Gatekeeper, an application server plug-in. With this setup, the Reactivity Gateway issues and signs a Security Assertion Markup Language (SAML) assertion for every processed message. At the application server, the Reactivity Gatekeeper inspects the message header for the signed assertion, verifies its validity, and either accepts or denies the message. Rejected messages can be sent back to the Reactivity Gateway.

While the future of Web services calls for application-aware intelligence, it's not clear where those smarts will reside. Today, leading firewall vendors--most notably Check Point--are working to add Web services intelligence to their existing products. Meanwhile, the Web services security appliance vendors are making their software available to other OEMs. Forum, for example, offers a PCI card version of its Sentry Web Services Security Gateway. Over the near term, network architects will likely gain better XML awareness through XML-specific firewalls. Over the longer term, much of that intelligence may find its way into a general-purpose protection platform.

ROUTING

Today, Web services are for the most part point-to-point links between departments or organizations. Where many interconnections between departments or organizations are needed, a central portal is typically used.

Yet as XML-aware networking develops and more Web services become the norm, both of these models will eventually break down or become unfeasible. What's needed is for companies to be able to notify others about their available Web services, then enable users to subscribe to those services as needed, forming a sort of virtual meshed configuration.Merely advertising Web services through the Universal Description, Discovery, and Integration (UDDI) protocol or describing them through Web Services Description Language (WSDL) isn't sufficient. Without WS-Addressing and two emerging standards, WS-Eventing and WS-Notification, nodes can't subscribe to a Web service in a reliable and predictable manner. The only products to implement these three protocols are DataPower's XS40 XML Security Gateway, Sarvega's XML Context Router, and Vordel's VordelDirector and VordelSecure.

Once a Web services connection is established, nodes need to be able to process incoming requests. Within financial services, for example, a request for a loan over $320,000 may be processed differently than a loan for under that amount. Policies must be set on the value of the loan and then route the Web service accordingly. Doing that requires type awareness, where the 320,000 represents an integer, not a text item. XML Path Language (XPath) 2.0 provides that type awareness, but not all products support it. Conformative's CSXi and Layer 7's SecureSpan products implement XPath 1.0.

In the end, network architects will need to look at the solution that best blends these diverse elements together and manages them properly. A management station that overlays all these elements is critical. The Actional SOA Command and Control Platform, for example, provides a platform against which companies can define SOA policies against business objectives. This sort of coherent SOA view will be critical regardless of which network appliances are chosen. At the same time, network architects must also be sure that such an SOA management platform can blend different vendors' XML appliances--not just work effectively with products from the same vendor. Ultimately, such an integrated approach is the best way to seal this report.

Executive Editor David Greenfield can be reached at [email protected].

Risk Assessment: XML Appliances

XML-aware appliances have matured beyond their initial introduction, with vendors such as DataPower already in their fourth or higher versions. With that development comes increased code stability, feature set support, and enhanced performance. However, XML and Web services are still emerging and will continue to evolve and develop over time. How effectively these appliances are able to adapt to those conditions remains to be seen.

The products needed to build an XML-optimized network are available today, but there are still areas of development that must be worked out, including interoperability and management issues. Depending on the vendor, an XML-optimized network is definitely feasible, but mixing XML appliances from multiple vendors may be another matter.

It's hard to find a major business that isn't at least interested in automated collaboration, which is what Web services and XML appliances promise. The combination will force CTOs and IT to examine ways to extend transactions throughout their increasingly diverse and distributed extranet.

Network architects need to tread carefully with XML appliances. Capital costs aside, some appliances run standardized OSs that aren't necessarily hardened against hacking. Like any appliance, an XML appliance implemented the wrong way could lead to a backdoor for some hacker to roam wild into the network.0