SOA - Service Orientation Applied

XML Appliances address this problem by providing a low latency scalable and performant way of processing XML messages. XML appliance features may be classifiedas "Basic" and "Advanced"

Basic features include: Encryption, Compression and Schema Validation. These features have been used extensively for 5 or more years, and are well established in the industry.

Advanced features include:

• Rules based validation using XPath and XSLT- messages that do not meet validation rules can be automatically rejected.
• XPath based search
• XML to XML transformation through XSLT
• Rules based validation using XPath/XSLT- Invalid documents can simply be rejected.
• XML to HTML transformation using XSLT
• XML Content based routing
• Conversion from flat files and legacy formats to XML(This feature seems to be available only in DataPower.)

Basic  features such as schema validation, compression and Encryption have been benchmarked at hundreds of megabytes per second.  It is a no-brainer to use XML appliances in this situation.

On the other hand, with advanced features, XML appliances run a lot slower. The speed at which XPath searches and XSLT transformation seems to depend on the complexity of the XML document, and the parsing task at hand. An aggregate XML message that simply aggregates hundreds of messages may be parsed very fast. But a XSLT transformation that does arithmetic calculations and complex transformation will run slower, typically 1-10 MegaBytes per second.

XSLT/XPath based transformations cannot replace work done in procedural languages such as C# and Java. Complex financial calculations, for example, or a validation that depend on other database systems or web services, must be done in C# or Java.

The claim that these appliances can replace an ESB seems farfetched. Intel has a Google campaign, that goes: Still using Tibco-Swith to Intel XML Appliance.(They repeat the campaign with other ESB vendors. )  ESB provides numerous features such as Protocol Mediation, Applying Business Rules, Assuring connectivity between Java and .net systems. It could be argued however, that the XML transformation, which can be a large part of the CPU usage of an ESB  can be offloaded partially/completely to an appliance.

XML Appliances provide performance benefit, as well as the benefit of lower latency.

The other advantage of the appliance is consistency of speed. Unlike a J2EE server that may underperform periodically due to other applications, or due to Garbage collection, an XML appliance performs at consistent speed.

The fully loaded cost of a J2EE or Portal Server can approach 100,000 dollars or more. Using this server for XML Transformations that can be done on lower cost XML appliances, is wasteful.

Skillfully integrating XML appliances with your ESB, Messaging and Application servers may provide critical performance benefits to your SOA initiative. It also changes the debate about the feasibility of using XML for intra and inter-enterprise integration.

In future posts, I hope to elaborate on integration of fine grained and rule based security using a XML Appliance, Deciding when to use XSLT/XPath, and integrating the appliance into the messaging and ESB infrastructure.