IBM Purchases DataPower Technology

Commentary
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

On October 18, IBM announced that it had purchased Cambridge, Massachusetts-based DataPower Technology Inc. for an undisclosed amount of money. DataPower Technology markets hardware appliances that speed and secure message traffic that flows through service-oriented architectures (SOAs). These appliances are black boxes that sit between servers and offload some of the XML processing loads so that software like WebSphere can run faster without needing to chew up cycles for XML security.

Working with Tivoli and WebSphere

DataPower currently markets three such appliances: one for boosting the performance of XML processing, one to add security to high-speed messaging processing, and one for message transformation and integration. These appliances integrate with IBM's Tivoli brand operations products, purportedly simplifying some of the management concerns that such devices might create. At the same time, they're designed to work with WebSphere, making it a natural add-on to organizations that are really focusing on WebSphere SOA solutions.

SOAs have been lauded as an important element in the future development of software, and many analysts believe SOAs will revolutionize how applications are built. However, the standards for Web Services and XML are still evolving, and as a result, security within an SOA has taken on increasing complexity and importance.

Promising SOA for On Demand Applications

The promise of SOAs lies in the potential to build applications on demand from disparate chunks of code and data that are distributed across the network. However, such a distributed assemblage of code and data also lends itself to security breaches unless there is a substantially robust security mechanism.

Unfortunately, the standard mechanisms for defining this kind of security--especially in the implementation of XML--are still being evolved, and there are ongoing and heated debates within the developer community about how these security mechanisms can be integrated best.

Complexity and Performance Considerations

Consider, for example, that a SOA defines how an application can be assembled as a Web service from potentially thousands of different, interchangeable parts located on a potentially limitless network of machines running different application servers on top of different operating systems--each with potentially diverse security mechanisms. If the goal is to bring these pieces together to create an on demand application like a Web service, there has to be both transparency of standards and innate and verifiable security. This is just one of the challenges facing organizations implementing SOA.

Moreover, one byproduct of this evolution of standards is that performance suffers because so much processing power is consumed in parsing security. Indeed, XML security processing is largely an XML processing nightmare. Complex cryptographic processing and the associated XML parsing, filtering, validation, and XPath/XSLT processing are extremely resource-intensive. Unfortunately, as a result, this security processing is sometimes simply turned off in production systems because it slows down the very transactions it's supposed to protect.

How XML Appliances Reduce Bottlenecks

Of course, analysts believe that evolving XML security engines--when they are finally mature--will provide robust XML security without creating performance bottlenecks. In the meantime, however, organizations that are developing their applications using SOA have to deal with the real world of performance degradation, and that's where DataPower Technology's XML appliances have found a market.

These appliances are highly sophisticated, dedicated micro-processors specifically designed to streamline cryptographic processing, XML parsing, filtering, validation, and XPath/XSLT processing. In other words, instead of chewing up CPU resources of the main server that is assembling the application, these appliances increase performance through dedicated hardware.

Why IBM's Purchase Is Significant

IBM's decision to purchase DataPower Technology is a powerful message that SOAs and Web services are approaching a new threshold of maturity and viability, especially for larger organizations. Why? Because in technology, as one moves programmable functions into hardware, one is acknowledging that the technology is starting to gel and become an accepted standard.

This is, of course, how telecommunication protocols led to the initial modem circuitry. It's also how the routing requirements of TCP/IP evolved into such products as Cisco Systems routers: Devices are first emulated as code using general-purpose micro-processors and later burned into firmware for greater efficiency. Finally, they are integrated into arrays of silicon circuitry, achieving maximum miniaturization and performance.

IBM is the first major player in the SOA environment to bridge this gap between SOA's evolving software standards and the implementation of those standards in a hardware appliance. IBM says it plans to use DataPower's XML appliance technology to further its support of WebSphere customers and to develop new products in the future, with announcements coming later in the year.

What could such a product line look like? How far could IBM take the concept of the XML appliance? Some analysts believe that while the initial products will be adaptations of DataPower Technology appliances, the sky is the limit as to how deeply IBM might delve into the miniaturization of XML processing.

A Hardware-Based SOA?

Just a few short years ago, applications were built specifically for individual hardware platforms. Consider, for instance, the evolution of the AS/400. On the AS/400, software consisted of the operating system and RPG. Neither could run on non-IBM boxes. The RPG compiled code communicated to hardwired terminals connected to the CPU using a proprietary twinaxial controller. This controller communicated through the twinax cable, sending a specific stream of bits that were uniquely designed to drive the IBM 5250 terminal devices. All of this composed something that IBM called the System Network Architecture (SNA). It was supplemented with a variety of communications protocols that were specific to the IBM hardware, such as Synchronous Data Link Control (SDLC).

When one stops to think about the complexity of the SNA, one begins to realize that the majority of the working intelligence of that architecture was almost entirely implemented in hardware. And it was implemented in hardware for purposes of performance. Within SNA, the software was by far the smallest proportion of the network's intelligence.

Role Reversals

Today, in SOAs, the significance of the roles of software and hardware are reversed. But do these roles have to remain separate?

The open standards process is allowing the evolution of Web services to progress swiftly, but it's also creating complexities that become performance hurdles. As these complexities are identified and as solutions are engineered, the code itself will begin an engineering journey from software to firmware to silicon circuitry.

Who knows? In the end, there is no reason why SOAs couldn't actually be composed of dedicated microprocessors and integrated circuits specifically designed to deliver and construct on demand applications across the network.

The Past as Prologue

When and if that kind of evolution occurs, we'll have moved substantially beyond the constructs of computing architectures that we are using today. Neither the operating system nor the CPUs running the code will be as significant. The network will be the computer.

But will we be looking at the future, or will we be looking backward through a mirror at the SNA of wire and steel that once ran our applications in days gone by?

That's the kind of question that XML appliances are fostering in the minds of industry analysts, and IBM's purchase of DataPower Technology is just a hint of the potential.

Thomas M. Stockwell is Editor in Chief of MC Press Online.

BLOG COMMENTS POWERED BY DISQUS