The differences between a hard and soft SOA appliance

In the last blog I wrote about the similarities and differences between a SOA "soft appliance" like Intel SOA Expressway and an ESB-based product.  Two key questions often arise out of that discussion: (1) Why do I need a SOA appliance if I already have an ESB, and (2) Why is a "soft appliance" better than an easy-to-deploy, secure and high-performance hardware appliance?

Both are very good questions and I will provide my opinion on each in this post.  First, the specific reasons for a SOA appliance in addition to (or sometimes instead of) an ESB vary somewhat case-by-case, but often fall into the categories of scalability/performance optimization and security optimization.

In the area of scalability/performance optimization, a SOA appliance is most often used to accelerate or offload XSL transformations, schema validations, SOAP message processing, XPath filtering, and content routing in high volume and latency sensitive information flows.  The simple reason being is that standard software libraries based on the most popular programming languages simply don't scale cost effectively in large volume and low latency use cases.  It takes a highly optimized XML and SOAP execution stack, like the one we have patented in software or specialized hardware.  Use cases such as high-volume business-to-business transactions, mission critical mainframe interfaces, and real-time interfaces for widely used financial, communications, healthcare, security and defense applications can't implement SOA design patterns on loosely coupled XML standards without this scalability and performance boost.  Also, the boost is not a nominal percentage increase, in nearly every use case we have encountered it is an order of magnitude increase from the low-end of 2x to the high end of several hundred times improvement (transaction throughput and reduced capital required).

In the area of security optimization, it is often desired to decouple security policy and enforcement from the implementation of a service, especially if the service is exposed on the public Internet.  In these cases, the SOA appliance is put in the DMZ and takes responsibilities for denial of service protection, coordinating authentication, authorization and audit logging as well as offloading compute intensive tasks such as encrypt / decrypt and sign / verify.  The performance characteristics allow this kind of processing to be inserted in the network "invisibly" between the client and the service provider offering a more reliable enforcement of security policy, reduced cost of development as new security policies are introduced or existing policies are changed, and allows for more seemless addition of advanced security controls on existing applications and other IT assets.

Ok, then so why is a SOA "soft appliance" better suited to these usages than a XML hardware appliance?  The answer comes down to cost and flexibility.  Both are capable of high speed XML acceleration and offload.  Both are simple to install and adminster.  And, both are security hardened to be deployed in DMZ-based security optimization scenarios.  However, with most hardware appliances there are little to no extensibility hooks to support varied data formats, custom network protocols, incremental expansion cards (for networks or crypto acceleration, etc.), or new standards without the appliance vendor publishing a new build.  In the domain of cost, development and test editions require physical devices making it hard to do agile, offshore, and parallel engineering cycles.  Also, as Moore's Law continues out in time each new generation of hardware results in a complete re-investment.  Old appliances can't be readily re-purposed like older general purpose servers and quite often are simply "thrown away".

Thanks for getting this far.  I look forward to hearing from you about your mission critical use cases that have high volume and / or low latency performance requirements as well as those which have complex security requirements.  Now that we have covered the overview of a SOA "soft appliance", in my next few posts I will focus on deployment and use models where this technology is best suited for use.