The idea is to add more flexibility to the job of parsing, threat prevention, and mediating XML messages so you could ramp up capacity on demand. By supporting real-time download and support, you could conceivably activate XML firewall capabilities on a moment’s notice, although that strategy would only work if you’ve already been through the configuration process with other instances of the firewall.

For scalability, the new virtual appliance supports clustering, so it could run as a virtual partition in one or more nodes, and it can run in multi-tenant data centers that are already relying on virtualization.

Our View

At some point virtualization was bound to hit the world of XML processing. It’s been coming to the components that surround the XML layer, as providers like IBM, Oracle, and BEA proffer virtualization strategies for their Java middle tier platforms.

And for a task as compute-intensive as processing XML, which includes parsing messages, vetting them for security, and/or mediating or routing them, virtualization makes too much sense. It’s especially an advantage for the scenarios put forward by virtualization advocates: that if demand for services in your SOA environment spikes predictably or unpredictably, the advantages of buying the black box appliance are largely negated.

The drawback is that no matter how efficient the virtualization layer, it will add some overhead to a task that is already quite compute-intensive to begin with. On the other hand, 20 years ago database admins voiced the same concerns about relational databases, only to find that more powerful hardware brute-forced the solution.