As a child of the 80s's I lived under an umbrella of fear surrounding nuclear everything. Living fairly close to a nuclear power plant, we all heard the words "chain reaction" a lot, and though we didn't understand the science we did know that it was a Very Bad Thing^TM and like children in the 60's we were taught to hide under a desk in the event of a catastrophe.

Now, one of the benefits of SOA is reuse. Business services provide consistency across multiple applications when they are reused both for data and for processes. This is a Very Good Thing^TM. 

However, reuse carries with it some fairly onerous consequences that can escalate to IT catastrophe status as well, among them those that come with any device or service becoming a single point of failure.

When one application suffers an outage it's a problem, but not a catastrophe. When five applications suffer an outage at the same time that's a catastrophe. Unfortunately if you're part of an organization in which SOA is being relied upon to provide the backbone of your application infrastructure, the "chain reaction" catastrophe scenario is a lot more likely to happen to you than it ever was to us in the 80's.

Reuse is a huge benefit, but it's also a huge risk. If a single service upon which multiple applications depend suddenly becomes unavailable, then all its dependent applications are also, necessarily, unavailable. A problem with a core business service can leave your entire business offline.

So imagine what might happen if an XML-based attack makes it to one of the core business services that comprise your SOA. Exactly. Catastrophe. And when the IT sirens go off you can't simply hide under a desk and wait for the danger to pass. Well actually you can, but your boss is likely to find you eventually. And he won't be happy when he does.

There are many good reasons to centralize SOA security, performance and agility (flexibility) being two very good ones. But perhaps the best reason of all is risk mitigation; minimizing the risk of catastrophe that could easily befall your organization should a core business service suffer an attack and be left unavailable.

Deploying a comprehensive XML/SOA security solution at the edge of your infrastructure, essentially at entry point into your SOA, is one of the best ways to mitigate the risk of a SOA catastrophe. By preventing XML and general application attacks from reaching critical services you can reduce the risk associated with reuse, SOA, and XML.

Many attacks are simply DoS (Denial of Service) focused: exceedingly large messages, excessively nested elements, and recursive parsing attacks. These attacks will not always - but can - cause a complete denial of service (how apropos, this attack name) across all dependent applications because one service is consumed with parsing a malicious request.

Other attacks are more well understood, as SQL injection looks like SQL injection whether it is transported via URL encoded variables or XML elements.

Regardless of what the attack is, it's best to stop it before it gets anywhere near those critical services that power your applications and, by extension, your business. When the result of a successful attack on a service is a "chain reaction" that can bring down core business applications, failing to mitigate that risk as fully as possible makes about as much sense as believing a wooden desk will stop a nuclear blast from vaporizing you.