One of my friends has a child who used to bring a blanket with her wherever she went. It didn't matter that it was a hundred degrees outside; she carried it more for comfort than to keep herself warm and safe. Not that it protected her in reality, but it provided the illusion of safety, which is often as important.

When Web services first burst onto the scene, which in my mind was the beginning of the SOA movement, one of the biggest challenges faced by early implementers was the perceived lack of security. Fear and uncertainty abounded, and it was years before the majority of IT organizations became comfortable with the level of security that could be provided.

What I find interesting at this juncture, when SOA is now a fairly well-established architectural paradigm, is that in many ways Security is the security blanket (you had to know this was coming) of SOA.

In looking at implementations of SOA and working with various organizations that are doing the implementations, I've begun to question exactly how vital security is in the overall scheme of things.

Don't get me wrong, I'm a proponent of security and I take it seriously - I'm not suggesting that security is unnecessary, or even that it's just a "nice to have." Far from it. At the same time, I think there's a difference between applying every security concept on the planet in the paranoid hope of keeping data "safe" and the intelligent application of concepts at the appropriate levels.

I've seen systems in the past that were brought to their knees by the improper application of security concepts. SOA implementations are equally vulnerable to poor implementations or improper use of techniques. Indeed, the nature of SOA makes it even easier for a mistake to cripple a service or even the entire architecture. All it takes is a service whose usage grows faster than expected to outstrip the capacity of a poorly planned security scheme and bring an organization to a crashing (and I do mean crashing) halt.

Sense, common or otherwise, must be applied to the design of a service-oriented architecture, especially with respect to security. If you've already authenticated a user, do you need to reauthenticate for every call? Does every field have to have security, especially if the service is for internal use only (or some other use with similarly limited vulnerability)? These and a host of other similar questions must be asked, and re-asked periodically, in order to ensure that the proper application of security will occur.

It's also useful to analyze the composition of a business process for just where security needs to be enforced. A common tendency is to consider every service as the proper level of granularity for enforcement. At the surface, approaching each service as the place to implement security seems reasonable, and many times it is. But some services are never called directly, or some convey information that has no value outside the context of the larger process. It may be sufficient to enforce security while entering the business process, rather than enforce it repeatedly at each step of the process by checking each and every service. A blind adherence to guidelines is very similar to carrying that blanket - it provides the illusion of security, without any real protection.

Security is a vital component of SOA; there should be no question about that. The ability to protect data, transactions, information and even networks from malicious attacks from without or from within is critical to many SOA implementations. But it must be applied intelligently, not blindly, for it to be an effective component and not simply a performance detriment.