Truth in SOA

I was at SOAWorld 2008 yesterday and had the pleasure of hearing David Linthicum's keynote presentation entitled "SOA by the Numbers".

One of the powerful messages he made was that the era of "management by magazine" is over and the fact that there are less SOA projects starting implies not that SOA adoption is waning, but that more projects are in-flight. This will inevitably lead to a scaling problem as SOA scales from micro-domains (also called the "little-bus") to macro-domains (also called the "big-bus") where the benefits of SOA are amplified for the business. Currently, other than Intel and and few other players, most vendors have been focused on the micro-domain with the proliferation of ESBs.

While I agreed for the most part with David's point about having a true services strategy and the right people for the job, these are truisms - the fact remains that SOA is steeped in technology right now. The line-of-business doesn't care so much about implementing SOA for its own sake, they are thinking in business terms where SOA is of instrumental or utilitarian value - a means to compete and not an end in itself; I think this is part of the adoption challenge as SOA is driven internally at the micro-domain level by software architects and engineers.

SOA promises to bring increased agility to business, but it seems that there is a philosophical conflict between purpose-built hardware appliances and the design principles around SOA. Typically, hardware appliances have been used as XML Firewalls or Web Services Security gateways to provide trust enablement, authentication, perimeter defense, and XML acceleration functions to a partner B2B scenario. The problem here is that providing this in a "mysterious black box" seems odd to me.

In particular, we can break down the concept of SOA Agility into four components: Network Performance Agility, Business Processing Agility, Development Agility, and Security Agility.

Network performance agility is the ability of the network infrastructure to closely match the necessary architecture for the deployed services. Business processing agility is the capability of the services to match the business mediation or required business processes. Development agility is the capability of the SOA infrastructure to support a distributed development team across geographic boundaries (typical of modern enterprises), and finally, security agility is the capability of the infrastructure to support changing security standards, evolving threats, and an "open" process for security analysis.

It seems that purpose built appliances from companies like Vordel or IBM DataPower represent an opposing force for each one of these SOA Agility areas. We can summarize SOA Agility, its aspects, and how hardware appliances seem opposed to SOA Agility in the following table:

Requirement	Hardware Appliance	Explanation
Network Performance Agility	X	Fixed NIC ports - supporting larger networks means buying more proprietary appliances. High Data center Costs - High TPS/Watt Usage over general purpose servers. Low Reusability Potential - Old appliances must be discarded or returned to the vendor, unlike general purpose servers which can be reused. Lack of Virtualization - Appliances have no capability to take part in data center efficiencies achieved through virtualization.
Business Processing Agility	X	Non-extensible - Impossible to add custom business processing on the appliance without a new feature request or vendor upgrade (possible hardware upgrade). Lagging Standards Support - Keeping up with all of the latest standards requires a full-cycle hardware upgrade
Development Agility	X	High Development Costs - Distributed development teams require additional high cost (generally $50K - $60K) appliances just for application development. The cost of the appliance approximates the cost for the developer! Serialized Development - Due to their high cost, development teams must often share a small number of appliances, cutting down efficiencies for business agility
Security Agility	X	Guaranteed Standards Lag - Latest security standards on hardware must wait for a full-cycle upgrade. Guaranteed O/S Security Lag - New security vulnerabilities in the underlying O/S actually running the appliance mean the customer must rely on the vendor for a patch. Inflexible Security Model - Additional monitoring, security and maangement software can't be added to the hardware appliance due to its "closed" nature. Security by Obscurity - Because appliances are proprietary black boxes its often not clear how security policies such as key management or user accounts are really handled. Did the vendor put in a back-door for management or support purposes? Who knows?

Rather than a hardware appliance, why not just achieve the same thing with specially optimized software that supports SOA agility?

I was perusing the Open Virtual Machine Format Specification and I was a bit surprised to see that they reference SOA in the third paragraph of the executive summary of the OVF Whitepaper.

"Whereas current virtual appliances contain a single VM only, modern enterprise applications model service oriented architectures (SOA) with multiple tiers..."

One of the benefits of OVF is that it can represent and package multiple virtual machines in a single package, which is great for modern, multi-tier distributed applications. If enough vendors jump on board this might help simplify what I see as one of the great barriers to SOA adoption: The huge crowded and confused market of non-interoperable SOA products from large vendors (including open-source). My favorite example of this is the proliferation of SOA suites. For example Sun JCAPS requires 13 components for installation. Is this all necessary?

Anyhow, one other thing I noticed about OVF is that it doesn't use W3C XML Digital Signature for its integrity checking scheme, but instead packages the signature and public key in a file in Base-64 encoded format (as a side note, I hope the reference to SHA1 on line 264 is a typo, it should really be a signature algorithm, e.g. RSA-SHA1), otherwise they'll have a tough time verifying it. I don't think this is necessarily a bad thing to not use W3C XML Digital Signature, but it does seem a bit inconsistent given that OVF is an XML-based specification.

Perhaps they are worried about the notorious poor performance for XML Signature processing on standard (un-accelerated) software offerings? Even in this case, if OVF went with XML Signature, the performance impact should still be minimal because the signature is over a list of 20 byte hashes, not an entire virtual machine instance, and even if it were, it wouldn't be an XML representation so there should be no canonicalization applied to it. In fact, XML Signature can replace the .mf, .ovf, AND .cert files. XML Signature already models the signature targets as a list of hashes and has a mechanism for including an X.509 certificate. Again, simplicity rules - why use three non-standard files when you can use 1 file that is an approved W3C standard?

As a side note, Intel's SOA Expressway Product solves the performance issues with XML Security processing with special Intel Multi-Core optimized software that is simply ideal for this type of virtual appliance model. I think OVF and software appliances might be a real boon to solving the SOA complexity problem.

Blake

And so it begins...

The goal of this blog is to be a sounding board for topics that lie at the intersection of SOA security, and business, with a particular focus on cutting through the insidious "hype" that surrounds many of the topics related to Services Oriented Architecture.

Stay tuned...

P.S. I am an employee of Intel Corporation and these opinions are mine and not those of my employer. Also, I may make some references to Joe Natoli's blog at blogs.intel.com as he talks about Intel(R) SOA Expressway.



Blake