I almost don’t dare to use the acronym SOA anymore. According to the latest news it is death and probably buried by now. But … long live services! And indeed, SOA has become a synonym for Grand Projects (with governance, business process improvement, methodology, enterprise integration … as small side projects). Needless to say that these projects either fail (for those who are lucky) or continue, without delivering much, until the end of time (for those who are unlucky). People forgot it’s all about a simple yet powerful architecture that uses services as a mental model.
Even without SOA on the whiteboard and focusing on “just services”, most organization manage to screw that part up to. For them, services = web services = soap. So, they start to spit out “services” after “service”. Of course, in reality they are just spitting out SOAP binding after SOAP binding for .NET or Java methods. It should be considered a crime to call this “services”. Language and tool vendors have made it very easy for these organizations to create services in this way. It takes a couple of mouse clicks and a wizard or two to turn any class into a full fledged “services” (read: expose it with SOAP).
This library, bravely called “ServiceLayer” even takes this a step further … Forgot to create a “service” from your classes? No worries, you can now create a service from them, without recompiling. You just browse the compiled code and select the methods you want to expose as a service. If this continues the very word “service” will become so tainted we can’t even use that anymore.
A good read on how to suck at information security. I can recognize a lot of the bullet points in the organizations I have seen and even warned them for a fair number of those.
We all know at least a couple of Top 10 lists of security bugs. Probably one of the most famous is the OWASP Top 10. This excellent article argues that these lists have the potential to do more harm then good. Some typical harmful effects could be (and I have witnessed these first hand):
- People judge the quality of their code based on these lists, thereby ignoring that the list is just that: a subset of things to avoid.
- Instead of learning how to write good code, developers learn how to write code that avoids some common errors.
- It does not educate people, new types of security bugs are only avoided when they appear on an updated version of the list.
I do agree with the above linked article, top 10 lists are not as innocent and helpful as they look. But I also have to admit that waving a top 10 list has helped me in the past to sell the idea of secure coding.
There is one argument of the article I would like to highlight. Focusing on lists of security bugs diverts attention from good designs. It is perfectly possible, in fact very likely, to have very sound designs that deliver on all requirements, functional and non-functional but fail miserably when security and risk is taken into consideration. Each time I had the opportunity to analyse a design in terms of its ability to be secure and behave predictable in the face of (partial) failure, I found that all of those designs suffered from serious risks. Risks that have a high impact and a much higher likelyhood of happening compared to hackers invading your network. Statistically it is much more likely that a software component starts to spit out erroneous data to its environment then it is likely that hackers invade your network and delete all your business data. Both have the same impact though. I bet you spend more money on keeping the hackers out then you are spending money to design for failure.
How many architects or developers take into account failure of components? What about partial failure? Does your solution support you in detecting and recover from those failures? Design for failure!
In a previous post (Disturbances in the cloud) I described that using services in the cloud (or more down to earth: on the Internet) introduces more risks then most users imagine. A new examples seems to be the (free) AOL Hometown service for site hosting. It was shut down on Oct. 31, 2008 leaving all users behind with no access to their own content. Some say they had a 4 week notice but the support forums seem to at least indicate not everyone got it. This was the only “official” notice of the imminent shutdown, a small blog entry.
More information can be found here.