始めに ソフトウェアパターンとアンチパターン があった。それがさまざまなベンダや実務担当者によって SOA と Webサービス に適用された。そして今度は，数年前 SOA アンチパターンの記事 を書いた Steve Jones 氏による アンチプリンシプル(anti-principle)の提案 である。氏の定義するプリンシプル(原則，principle)とは ...
[...] 何かを評価しようとするときの，中心となる概念です。
[...] すべてが上手くいかないときにはアンチパターンが指針を与えてくれますが，同じように計画を進める上で回避する努力をするべきもの，それがアンチプリンシプルなのです。
Steve は手始めとして "疎結合(Loose Coupling)" や "インターフェースの明確化" など SOA の原則(プリンシプル)を紹介した上で，この種の原則がリストアップされることはよくある が，アンチプリンシプルがリストされる(あるいは議論される)ことはめったにない，という事実を指摘している。回避の必要な問題を示してくれるアンチプリンシプルがより重要であるにも関わらず，である。プリンシプルについては，オンラインでもオフラインでも少し検索してみれば，Stefan Tilkov 氏や Thomas Erl 氏，その他の人々 がリストアップしたさまざまなエクスペリエンスを確認できる。反面，アンチパターンについては文書こそいくつかある が，うわべだけのものや相手にできないようなものがほとんどだ。
では，よい SOA アンチパターンとはどのようなものだろう？ Steve が考えてみているが，他にもありそうだ。
- 小さな戻り値: "バッチインターフェースを使用する場合に，単なるコードを戻り値としておいて，問題を特定するためのレポートを解説として提供する，というものです。要するに十分なデータを返さずに，コードとその説明のみを提供する，ということです。"
- 直接呼出し: "このアンチプリンシプルは，取得した WSDL をプロキシなどの中継ぎを介さずに直接利用する，というものです。これは自殺行為的なプログラムです。やってはいけません。"
- インターフェース生成: "アンチプリンシプルでは，インターフェースはコードから生成するのではなく，前もって設計し，明確に作成されるべきである，としています。"右クリックで WSDL 生成" 方式の IDE アプローチによる Web サービスの公開は，アンチプリンシプル的には禁止事項なのです。"
パターンを主題とした最初の本 のリリース以降，何年にもわたって，技術者やプロジェクトに対するパターンの有益性に関する数多くの書物 が書き続けられてきた。パターンの(再)利用とアンチパターンの回避は，もはや大部分の開発者にとっての習慣とも言えるものになっている。しかし Steve の指摘するところでは，プリンシプルとアンチプリンシプルについてはいまだその重要性の多くの部分が，少なくとも SOA に関しては見落とされたままの状態なのだ。