IBM Plugs Into DataPower
The deal secures XML's place in IBM's service-oriented architecture (SOA) plans. IBM aims to make application deployments more flexible for service providers and enterprise networks alike. So far, IBM's interest appears to be in the enterprise use of XML. DataPower worked on bringing XML into telecom circles (where equipment would use XML to talk with back-office systems, for example), but it's yet to be seen whether IBM will give that direction any emphasis.
For now, IBM is devoting its attention to fitting DataPower's appliances with the WebSphere line of software, and has plans to develop SOA appliances based on DataPower's technology. (See IBM Acquires DataPower .)
Terms of the deal were not disclosed. DataPower CEO Jim Ricotta will continue to manage the DataPower crew and will play a role in IBM's software group as well, IBM said in a release.
The term "SOA" refers to an environment where applications talk to one another even if they reside on different computing platforms. The goal is to create a more flexible delivery of services on the network. The idea has captured the hearts of big application vendors like BEA Systems Inc. (Nasdaq: BEAS), IBM, and Oracle Corp. (Nasdaq: ORCL), but it's still unclear whether the SOA will take over the data center as we know it. (See Oracle Sets Sights on SOAs, BEA Picks $200M Plum, and SOAs: Approach With Caution.)
With applications becoming increasingly Web-based, many companies like the idea of using XML -- already used frequently on the Web -- as the common language betweeen applications. Hence, IBM's interest in DataPower, which makes systems that accelerate XML processing.
XML has been around for years but has only recently become a hot property with big companies. snatched up Sarvega Inc. in August. And (Nasdaq: CSCO) began to touch on this area with its Application-Oriented Networking (AON) technology, aimed at making networks more aware of the applications they carry. (See Intel Absorbs XML Startup and Cisco Speaks Applications.)
Relatively few applications have gone to native XML messaging to communicate with one another, but IBM seems to think the trend will accelerate. IBM would appear to be hedging its bets between the MQSeries -- its "old-world" middleware platform for messaging -- and the bright shiny new world of XML.
"The next shift is to an object-oriented form of distributed application that is Web-enabled and peer-to-peer -- and here's where the old types of middleware run out of steam," writes Heavy Reading analyst Caroline Chappell in an email to Light Reading. "The new companies bubbling up in this area want to ensure they can underpin the new paradigm, and IBM obviously thinks it's best to buy one of the few hardware companies here than try and build something itself."
It's uncertain whether a frenzy of XML acquiring will ensue, however, because there isn't a lot to get frenzied over. "There are very few hardware companies working in this area at the moment, but quite a few new middleware software-only players, like Kabira," Chappell says.
DataPower has been around for six years, and most other XML players are even younger -- Solace Systems Inc. announced its first product, an XML message router, only recently. Others such as Sonoa Systems Inc. and Xambala Inc. remain in stealth mode. Chip vendor Tarari Inc., spun off from Intel in 2002 to market an XML accelerator, might be the senior member of the remaining startups. (See Telecom Startups Play in XML.)
Even as XML's importance grows, a debate is beginning to stir about how best to wield it. DataPower, Sarvega, and Tarari have concentrated on XML acceleration, often offloading the processing of the XML language from some other device. Cisco and Solace, by contrast, embed themselves in the network and aim to process messages at wire speed.
This dichotomy has sparked the usual debate about how intelligent a network should be. According to Chappell, the recent Light Reading Webinar on Application/XML-Aware Networks ended with "skeptical questions" about whether the Cisco/Solace approach risks "overloading the network and adding unnecessary complexity."
— Craig Matsumoto, Senior Editor, Light Reading