SOAPベースのwebサービスを複雑にしている主要な原因の1つが、サービス インターフェースを記述するのに使う Web Services Description Language (WSDL) の使い方にある。William Vambenepe 氏によると、WSDLに関するもう1つの問題は、WSDLとそれを使ったスタブ生成ツールが余りに互いに強く結合した、分散アプリケーションを生成することである。人々がこれらの問題を認識し始めると、サービス定義を改善するのではなく、
... 人々は、サービス記述の全ての考えを投げ捨てた。そして、今は、APIの時代で、アプリケーションのコントラクトの点で、現在は、15年前から進んでいない。これは、悲劇である。
投稿の中で、氏は、そのような決定を正当化するのに一般に使われる、2つの重要な間違った考えについて論じている。
- ある1つのサービスに適した真の記述は、1つだけではない。 氏が言うには、
自動的なシンタックス検証に焦点を当てるよりも、特別なニーズに合うように最適化されたサービス記述にする方が、絶対にいいのである。サービス契約のすべての利用者が同じ記述を使う必要があるわけでは、無い。違ったユーザと／あるいは目的にあった、違ったサービス記述にすることは、問題ない。
氏は、投稿で主に、あるサービスに対する異なったフォーマットについて述べているが、彼の言っていることは、ずっと広い範囲に当てはまる。技術者として、長い間、我々は、開発者（APIの定義）向けのサービス記述ばかりに注目していて、ビジネス アナリストのニーズを無視してきた。彼らは、特定のエンタープライズの問題にサービスを適用できるかどうかについて、決定を下さなければならない人たちである。一般的に、彼らは、「従来の」API定義（サービス記述）をずっと超えたサービスについての情報を必要としている。例えば、
- そのサービスは、どのようなビジネス上の機能を提供するのか？
- サービスの限界は、何か？
- サービスは、どのSLAをサポートするのか？
- サービスをうまく起動ために、サービス リクエスタが満足しなければならない要求は、何か？
- どのような条件の下であれば、特定のサービス実行によって結果が生まれるのか？
- サービス記述は、メッセージの検証をしなければならない、という意味ではない。 氏が強調するのは、
サービス記述が役立つ方法は、他にもたくさんあったが、シンタックス検証とスタブ生成に注目したために、そのようなことは、殆ど無視されてきた。
サービス記述のいくつかのユースケースとして、投稿にあったのは、
- ポリシーやSLAを付ける。氏が説明するのは、
WSDLがしばしば使われる用途の1つが、ポリシーやSLAを付けることである。この目的には、XSDメッセージ定義は、全く不要である。必要なのは、ポリシーやSLAを付ける作業を特定する方法だけである。このためには、WSDLよりずっと単純な言語が使えるだろう。しかしもしあなたが、記述言語のまさにそのような概念を投げ捨ててしまったら、風呂水（シンタックス検証のメカニズム）と一緒に、大事な赤ん坊（サービスによって処理されるリクエストの分類）まで捨ててしまうことになる。
- 統制／バージョン管理 サービス定義が変わったときに、発見する能力
サービス記述文書を持つ事による恩恵の一つは、それが変わったときにわかることである。例えこれを単純な2値に縮めてしまう（私が前回チェックした時から変わっているか、yかn）場合でも、価値はある。もし、変更によって影響を受けるリクエストがどれかを見るために、その記述文書を調べられるなら、更によいことである。そして、その変更が後方互換かどうかわかれば。
- ポリシーやSLAを付ける。氏が説明するのは、
公式のサービス記述は、確かに重要である。WSDLの欠点が、その完全な破棄の根拠であるべきではない。もしサービス記述の次のバージョンが今日のWSDLあるいは Web Application Description Language (WADL) 、すなわち「マシンが読める」サービス記述を超える事が出来れば、それは素晴らしい。結果的に、サービス記述は、API定義以上のものであるべきであるが、サービスのライフサイクルに参加しているすべてのステークホルダーを満足させられるものであるべきである。