Another reason for DataPower SOA appliances - XML Threat Protection

I've gotten a few questions on recent XML security buzz. On today's blog post by Rich Salz (lead architect of our appliances) discussed how XML threat protection is a required tool when exposing important services to untrusted sources. He talked about this due to the recent press interest in "XML Exploits" which was started by some XML fuzzing work by Codenomicon.

I wanted to post about it here to make sure this wasn't an unknown concept to our customers. Rich talks about "defense in depth", which is what most of our WebSphere customers are doing today. To quote Keys Botzum (one of our lead security consultants for WebSphere, "Anyone that is exposing services to untrusted sources absolutely needs to be running a XML firewall, like DataPower)". In my world, defense in depth means putting a WebSphere DataPower XML Security Gateway XS40 in front of any services that could be called by untrusted sources. Also, given the performance characteristics of the DataPower devices (basically no latency impact), you likely want to do this on all services (as sometimes hacks aren't intention and sometimes hacks come from internal sources).

If you haven't heard of XML firewalls or XML threat protection, think about network firewalls. Network firewalls are great for protecting us from threats that can be detected at the network level (like the recent Twitter and FaceBook distributed denial of service attacks), but they don't help you with threats that are in the payloads of messages themselves. XML Firewalls help you with such application level threats by turning away bad messages before they enter your enterprise applications.

If you have any questions on the concept, feel free to pop over to Rich's blog and ask.

More information on the TPC SOA benchmark

As I mentioned previously, the TPC (Transaction Processing Performance Council) is looking at SOA benchmarking. SearchDataCenter.com has an article that summarizes alot of the new and upcoming TPC work. You will see the TPC chairman, Mike Molloy, talk about the popular existing TPC benchmarks (TPC-C, TPC-E, TPC-H, and TPC-App) as well as new benchmarking efforts around energy (consumption with focus on greening of the data center), virtualization (across all new workloads), ETL (Database Extract, Transform, Load), and SOA.

On SOA, Mike explains, "TPC's SOA benchmark is only in the proposal stage, but the tentative plan is to focus on common industry-accepted portions of SOA infrastructure, mainly Web services, the enterprise service bus, and business process choreography. As advanced SOA practices become more standard in the industry, TPC will expand the benchmark to incorporate additional SOA infrastructural services".

I'm excited to work within the TPC to continue driving this SOA performance benchmark to reality. There are no other standard benchmarks that tackle these common SOA infrastructural components. If you have interest in seeing such a benchmark or comments on how it would help you, please post a comment. I'll relay them back to the TPC.

SO-UH... IT SOA Part 4. No, really separation of concerns.

From the previous blog site, I've had 3 entries on exploring why the SOA vision isn't really hard -- not to be confused with the reality in the industry -- which is nonetheless quite difficult to sort through. At any rate, so far I've stated that Service Orientation is important because it gives the industry a common approach to develop, design and speak of distributed applications; that in order to be successful, SOA principles must at its heart embrace our existing technology; and that finally, a greater level of flexibility can be achieved by ensuring that our service consumers and our service providers have a level of independence -- an appropriate level of separation of concerns, such that provider implementations can be changed with independence from and of the consumers.

To really achieve a separation of concerns between the service consumer and service provider, it is often beneficial to introduce the concept of service virtualization. Service virtualization is the concept that we don't actually publish the concrete service provider to consumers, we publish an intermediary which exposes the formal service interface and business contract. In its simplest form, the intermediary is really just a pass-thru which merely passes parameters and context to the real, concrete service provider implementation. In more complicated forms, dynamic decisions can be added to the intermediary to choose the most appropriate service provider implementation. A very simple business example is the famous "getStockQuote" service. Some stock quotes are delayed 20 minutes but are free to obtain; whereas real time quotes usually cost the consumer a small fee to obtain. Both provide the same service, one has a greater expense to the business, but better quality of service. This intermediary is sometimes called a mediation.

Service virtualization is one of several beneficial aspects of Enterprise Service Bus patterns.

Bottomline: Separation of concerns is a good thing to build flexible, agile applications. Best practices and newer programming constructs can achieve a good deal of separation of concerns. Service virtualization complements these concepts, and extends separation of concerns to older programming styles, patterns, languages. Service virtualization facilitates us embracing legacy applications, utilizing them where they are hosted.

Steve Kinder