Truth in SOA

I recently noticed this great article on XML appliances published in March 2010. The thing is, I didn't see any mention of Intel(R) SOA Expressway, which is the modern incarnation of the hardware XML gateway brought to market by Sarvega as early as 2000. At Intel, we call this product a service gateway, which can be thought of as a higher-performing, more flexible gateway that more closely matches current performance, extensibility, and data-center trends compared to its earlier hardware only cousins.

I think the author did a great job of mentioning some of the salient points regarding XML gateways, such as the need to push policy enforcement to the edge to simplify coded-in security (decoupling) and the need to provide XML acceleration for complex XML tasks such as transformation, validation, and XML security. He also alluded to some current limitations found in the IBM DataPower appliances:

But as powerful as IBM's XML appliance is, there is always room for improvement. One area where Iocola said the devices have trouble is handling large messages. To remain efficient, he said, the appliances need to offload messages approaching 2 GB to other components.
 
I also like the author's distinction between an ESB and an XML gateway, as this is often a point of confusion. Specifically, the author mentions that a gateway "doesn't host services", and this is true for traditional gateways such as IBM DataPower, but it doesn't have to be the case with a service gateway like Intel(R) SOA Expressway. I would also add that a big distinction between an ESB and gateway is that the ESB doesn't provide edge security protection or high-performance XML processing. For instance, ESBs typically don't have denial of service protection, content scanning, or message throttling. These tasks are more closely aligned with an edge security product such as an XML gateway.

So, what is the difference between a traditional XML gateway and a service gateway? Let's summarize a few points as follows:

• It must support a high performance virtual form factor. This means that performance of the XML gateway cannot require any customized hardware, such as special XML boards or chips.
• It must be extensible for new business logic and security processing. Enterprises cannot wait for hardware refresh for the vendor to add custom processing
• It must support all styles of services, whether based on REST, SOAP or even custom proprietary services based on custom protocols.
• It must scale XML processing on cheap commodity hardware. In this case, Intel(R) Multi-Core servers come to mind but AMD is also an option
• It must not require any specialized coding knowledge, such as deep XSL knowledge, extension functions or an army of developers. After all, if it did you would just invest in writing more code
• It must support non-XML data. While we can all hope that all companies will move their data-sets to 100% XML, it's just not a reality we can count on.
• It must support a wide ecosystem of middleware and security vendors for interoperability and integration allowing for a best-of-breed application.
• It must offer a physically secure form factor running on a well-known operating system with audit able patch levels rather than a custom appliance O/S subject to security by obscurity

Another way to think about a service gateway is that the product category is trying to bring more value to the security architect and developer in the data-center. If you are currently using an XML gateway and notice that many of these requirements aren't being met, maybe it's time to look at a service gateway such as Intel(R) SOA Expressway?