うまくSOAが使用できるかどうか(リンク)を尋ねる人たちを探すのに、遠くまで見る必要はない(参考記事)。SOAが成功したのと同じくらい多く、SOAが失敗した例がある。 さらに言うと、成功または失敗(参考記事)の裏(参考記事)にある正確な理由(リンク)は謎に包まれていることが多い。おそらく作成者が知らないか、もしくは機密性の理由から議論することが できないからかもしれない。そうは言うものの、成功の場合、一般的なスレッドの1つは精度およびプロジェクトの良いガバナンス/管理である。しかし、数十 年の経験(リンク)によって、演算の原則に基づいたシステムスペックおよび検証が非常によく機能するということが示されているにもかかわらず「正式」とか「メソッ ド」(リンク)という言葉が使用されるのを滅多に聞かない。
2007年、 WS-CDLに関するW3Cの取り組みについて議論した(参考記事)。当時言及されたように、WS-CDLはPi Calculusをベースにしており(PDF)、
CDLは他の人に必ずしもその詳細を公開することなく、各利害関係者の詳細レベルをキャプチャーする方法を提供することで、ビジネス利害関係者、ビジネス アナリスト、エンタープライズアーキテクトおよびアプリケーションエンジニアに、同期化された方法で同じシステムのビューを共有することを可能にします。 またCDLは必要な出所を提供し、各レベルで要求を実施する。こうしたやり方で、CDLはSOAでAを可能にする。その訳はアーキテクチャがモデル化さ れ、表現され、実装される方法を提供するからである。
数カ月後(参考記事)、Steve Ross-Talbot氏(リンク)(CDLの主要な推進者の1人)が、マイクロメーターに相当するコンピュータサイエンスとしてCDLをどう見ているかについて書いた。
... コードのラインがカットされる前、CDLの記述は要求に対して有効であることが示され、計算用語では正しいことが示されている(ライブロック、デッドロックおよび異例の状況がない)。
Steve氏は後退し(リンク)、CDLを支える方法論がTestable Architecture(参考記事)として知られてきた。この記事(およびビデオによる関連したプレゼン)(リンク)で、Steve氏は現実世界の(インフラベース)のユース ケースについて議論し、SOAの開発およびデプロイの所要時間を80%削減し、成功する可能性を向上させるためにWS-CDLを使用した。
その両方の場合においてその背景は、実行中のインフライトSOAのロードマップであった。ユーザエクスペリエンスを支援するために、そのロードマップは、レガシーアプリケーションの統合とポータルの開発を必要とした。
そして、氏はソリューション開発のために、最初の非CDLベースの評価を説明している。
最初の事例では、ソリューションを開発し、技術的なコントラクトを提供するために割り当てられた時間は、ほぼ15日程度の作業であった。これに含まれるの は、要求、機能、非機能の収集、データモデルをサポートするためにメッセージフォーマットを検討すること、ソリューションが効果的にモニタリングできるよ うに、ビジネストランザクションを理解すること、マッパーおよびメディエータサービス向けサービスコントラクトの提供、必要な個々のサービスの振る舞いを 示す状態ダイアグラムの提供およびコラボレーションコンテキストを提供するためのシーケンスダイアグラムの提供である。クライアント、メディエータ、マッ パーおよびレガシーサービスを含み、サービスの合計数は、4であった。
Steve氏は、2つ目の例はより複雑で、ほぼ60日程度の作業と推定されることを述べている。Testable Architecture方法論を使用し「UMLのような表記法」で構成し、CDLモデルのフィードのためシーケンスダイアグラムを作成することで、その ユースケースは取り組まれた。そして、これらのシーケンスダイアグラムに対して、テストされた。その結果は興味深い(しかし、科学的な側面から見ると、他 のどこかで意味を持つように再生される必要がある。)
最初のケースでは、要求を集め、テストされたモデルを提供するために、1日もかかっていない。2番目の場合、同様のことをおこなうのに、4日かかった。技 術的なコントラクト、WSDL、BPEL、BPMN、状態ダイアグラム、シーケンスダイアグラムなどは、CDLモデルから生成される場合、数回のクリック が必要である。その作業をおよそ80%圧縮したことは、幻想的および神話的のように、聞こえる。しかし実際、成し遂げた。BPELおよびWSDLの両方の 使用において、早い段階で設計上の欠陥を見つけたというものではない。競合する要求を見つけ、それらを訂正した。そして厳格および完全どころではなく、手 動でなんとか実現した正確さの技術的なコントラクトを作成した。
しかし、氏が指摘しているように、何かを上手に、正確に記述することは、必要なもの(または必要だと信じられているもの)をさらに理解することができると いう効果がある。開発前に認証可能で、ユーザに影響を与えることなく問題を調査することができる。また、同意がされた正式なメソッドアプローチのユーザ は、個別のコンポーネントを分離して開発することを可能にする。同時にデプロイされると、最後の実装が希望通りに機能するというより強力な基礎がある。も しくはSteve氏が言うように、
正式なメソッドを通じた記述の衝撃は、効率的により多くのことをおこなう方法を変えることに役立つ。そのため、ソリューションを表現する機能を失うことない抽象化のあるレベルへ、ソリューション開発の前プロセスを移行する。
すでに述べたように、1つのデータポイントでそのどちらかの方法を証明することは難しい。しかし、これらの結果が再生可能である場合、すばらしいSOAアーキテクトのツールベルトへの興味深い追加を意味するかもしれない。