First there were software patterns and anti-patterns, then they were applied to SOA and Web Services by a range of vendors and practitioners, and now Steve Jones, who wrote about SOA anti-patterns several years ago, has raised the topic of anti-principles. According to Steve, a principle is ...
[...] a core concept that you are going to measure things about.
[...]In the same way as Anti-Patterns give you pointers when its all gone wrong then Anti-Principles are the things that you will actively aim to avoid during the programme.
In the entry Steve mentions SOA principles including "Loose Coupling" and "Clear Interfaces", but points out that whereas people are often able to list such things, they often won't list (discuss) the Anti-Principles, which are often more important as they indicate problem areas to try to avoid. A quick search through the literature, both online and offline, illustrates a breadth of experience around principles, such as those listed by Stefan Tilkov, Thomas Erl or others. Although there is some literature on anti-patterns, most are either assumed or ignored.
So what makes a good SOA anti-pattern? Steve takes a stab at a few, but there may be others.
- Small return Values: "This is where people have been used to Batch interface where returns are just codes and descriptions with reports being used to indicate problems. The sort of statement here is just return a code and description rather than returning a decent amount of data."
- Direct Calling: "This anti-principle is all about where people just get a WSDL and consume it directly without any proxy or intermediary. Its programme suicide and it shouldn't be done."
- Interface Generation: "This anti-principle says that you shouldn't generate your interfaces from code but should design them up front and make them explicit. So from an anti-principle perspective you are banning the "right-click generate WSDL" IDE approach to Web Service exposure."
Over the years since premier book on the subject of patterns was released, there has been a lot written about the benefits they bring to engineers and their projects. While the (re-)use of patterns and avoidance of anti-patterns has become almost second nature to most developers, it seems that Steve has a point that principles and anti-principles are as important yet too often overlooked, at least as far as SOA is concerned.