SOA - Service Orientation Applied

Intel's appliance is not actually an appliance but a product called SOAExpressWay. It runs on standard Linux servers, providing the "benefits of having an appliance, with the flexibility of a server, while using commodity hardware".   

 The benchmark numbers are impressive, and are for a dual CPU Intel Box. I wish the benchmarks used Java 1.5, which is approved in many enterprises rather than Java 1.6, which is not. But I do not think the numbers will be dramatically different.  

 Want to protect your SOA infrastructure from being flooded by badly written XML that does not conform to your schema? This could be an external denial of service attack, or more likely an error at the XML producer end. With SOA and agile development, there is the advantage of incremental development, but it is coupled with the risk of error prone code getting into your production or performance/staging environment.  The Intel SOAExpressway can validate XML to a schema at the rate of 507 MB/second, on a dual CPU box.

Want to validate the data that has come in using simple XSLT based rules? The Intel SOAExpressway provides XSLT processing at very high speeds. For example, specific fields could have valid ranges, or be constrained based on values of other fields.

An interesting feature of the SOAExpressway architecture, that it is not a pure appliance- non-XSLT based validations written in Java or C++  can also therefore be done on the XML data. As pointed out in this  excellent presentation on parleys.com(see slide #20,21) ,  there is always something that is very difficult, if not impossible to do in XML.

Want to convert about 1 GB of flat file into XML? It should take about 30 minutes or less with the SOAExpressway running on a dual CPU Intel Linux server. A past engagement showed a data volume of 50 MB per hour exchanged with an external application service provider. It would have been very convenient to use an appliance to validate, transform and import/export data using a product like the Intel SOA Expressway. The flat file to XML conversion is comparatively slower.

XML to XML conversions run a lot faster. The benchmark paper mentioned earlier, shows XML to XML conversions running at between: 500 KB per second to 41 MB per second. This is on a dual CPU box. This is not "wirespeed" as most appliance vendors hype, but it is enough to meet the needs of  many enterprise or even consumer facing enterprise portal needs. For example, consider a WML page of 4 KB on a cellphone, which is refreshed every 60 seconds. Assuming a transformation rate of 20 MB per second, a dual CPU server could support around 30,000 users.

XPath execution speeds in the  benchmark paper ranged from 400,000 to 1.5 million expressions per second. Using XPath to perform rule based validation, is thus very scalable using the Intel SOA Expressway. Incoming XML document can be validated for consistency, such as "To-date" being greater than from date.

Why not use XALAN instead? The manageability features of the SOAExpressway including basics such as SNMP Trap creation, Email notification, as well as the more advanced features such as  application level end-point support  and  Scriptable management using CLI are critical in an enterprise environment. 

A common problem in many SOA Projects is creating a "sub-set" XML document, from a given XML document. For example: The XML provided to you has 250 fields, but you need only 10 of them, in your application. A standard pattern is to read the large XML document, parse it to discover the 10 needed elements. The memory consumed in this parsing operation, can be large, causing frequent garbage collections.  Performing this operation on Intel SOAExpressway should be a lot faster than in the application server.  Moreover, you are  performing the transformation on a server that is comparatively cheaper. A fully loaded dual J2EE  Portal Server can easily cost  upwards of $100,000 per fully loaded server. In one portal project, about 95% of the portlets, called webservices on the backend, and transformed the XML so obtained, to generate the HTML markup. The  XML transformation load could be a large fraction of the CPU use on your expensive portal server.

In a given project, thinking about using a XML appliance may be difficult, but if XML Transformation and validation are provided as standard services, then this technology can percolate into the mainstream of your enterprise.