Olaf Zimmermann氏はIBM Researchの同僚と共に、企業アプリケーション開発を促進することを目的として、Architectural Decision Metamodel（アーキテクチャ決定メタモデル）(PDF・英語)を昨年開発した。
アーキテクチャ決定の獲得は、アーキテクトとして活動している者にとって常に難題です。決定獲得を阻害する要因として、プロジェクトスポンサーによる評価の欠落、時間不足、ツールの不十分なサポートが報告されています
Zimmermann氏らは、3段階の決定獲得コンセプトのフレームワークを提案している。
- 決定の識別 - 現実には、決定の識別は個人的な経験にのみ基づいており、［しばしば］その場限りになっています
- 意思決定 - 現実には、意思決定者には往々にして先入観があります…。過去の経験…［あるいは］…業界のトレンドに依存しています
- 決定実施 - 現実には、コーチングやアーキテクチャのテンプレート、コードレビューが決定実施アプローチで優位を占めています
Zimmermann氏らは、構造化された積極的なアプローチを決定モデリングに提供することにより、以下を目指している。
決定依存モデリング、決定要因の一覧表、意思決定テクニックの推奨を用いて、意思決定の質を向上させること
2週前、Cesare Pautasso、Olaf Zimmermann、Frank Leymannは北京で開催されたWWW 2008コンファレンスで論文(PDF・英語)を発表したが、その論文で「RESTful Webサービス(source)と大型Webサービス(source)」を詳細にわたって比較し、「正しいアーキテクチャ決定」のための識見を提供した。
著者らは、それぞれの技術で認知済みの長所と短所を驚くほど詳細に考察している。企業アプリケーションの統合には、多数の異なる様式を使うことができます。［こちらを］選択すれば…大型アーキテクチャを決断したことになります。「大型」Webサービスの技術スタック（SOAP、WSDL、WS-Addressing、WS-ReliableMessaging、WSSecurityなど）は、リモートプロシージャコール（RPC）およびメッセージング統合様式の両方に相互運用性をもたらします。つい最近では、Webをまたがって遠隔にあるプロシージャを実装する代替ソリューション、いわゆる「RESTful Webサービス」が公開されました。
統合様式や技術の選択など、分散型システム設計で鍵となるアーキテクチャは、専門的な議論と各選択肢がもたらす具体的な機能の公正な比較に基づいて決定すべきです。それどころかWS-＊対RESTの論争は不幸にも、先入観にとらわれた宗教的な論争と化してしまい、混乱を起こし、満たされることのない期待のみを生んでいます。
この論文で［著者ら］は計量的アプローチを用いて、アーキテクチャの原則と決定に基づき、2つの統合様式技術を比較しています。
SOAPとWS-*スタック
SOAPのメッセージフォーマットとWSDLインタフェース定義言語はその複雑性が認知されているにもかかわらず、異種のミドルウェアシステム間に相互運用性をもたらすことのできるゲートウェイ技術として、広範囲にわたって採用されてきました。
現在のWS-＊ツールは、既存のソフトウェア・コンポーネントをいとも簡単にWebサービスに変換しますが、このツールがもたらしたパワーは、皮肉なことに誤用もできてしまうのです。ですから、抽出レベル全体でのリーク回避が肝要です。相互運用性の問題は、たとえば、ネイティブのデータ型とサービス実装の言語構成要素がそのインタフェースに存在している場合に、発生することがあります。Contract-Firstの開発のように、特定の設計およびコーディングガイドラインを提示・強制することにより、この弱点は緩和できます。
REST
RESTfulWebサービスは単純と考えられていますが、その理由はRESTが既存のよく知られているW3C/IETF標準（HTTP、XML、URI、MIME ）を利用しており、必要なインフラがすでに普及しているからです。...
最小限の作業でサービスの構築が可能な、こうした軽量のインフラは安上がりに手に入れることができるため、採用に対する障壁が非常に低くなっています。
［しかし］、RESTfulWebサービス構築で一般に受け入れられているベストプラクティスに関して、若干の混乱が見られます。Hi-REST勧告が非公式に定められましたが、いわゆるLo-REST実装では常に完全遵守されているとは限りません…［現実には］わずか２つの動詞（冪等の要求にGET、その他のすべてにPOST）のみが使われています…［なぜなら］プロキシとファイアウォールがこれ以外の動詞を使うHTTP接続を必ずしも許可するとは限らないからで、制限によって数々の次善策が講じられ、「本当の」動詞は特別なHTTPヘッダ（X-HTTP-Method-Override）もしくは、Ruby on Railsと同種の隠れフォームフィールド（−メソッド）のどちらかを使って送信されています。
著者らは次に、Architecture Decisions（アーキテクチャ決定）フレームワークに基づいて比較方法を確立する。この件に関する情報を用いて決定候補と代替案を識別した。RESTおよびWS-＊を使った場合の、アーキテクチャ決定を記録した統合シナリオを展開した。統合様式毎にひとつの決定モデルを作成したので、決断の数や決断毎の選択肢の数のような数的指標を用いて客観的に2モデルを比較できた…。
続いて、原則、コンセプト、技術を比較した。その際の発見は以下のとおりである。
原則レベルでは、2つのアプローチには似通った量的特性があります。
コンセプトレベルでは、WS-* Webサービスの決断時に下さなければならないアーキテクチャの決定の方が数的には少なくなりますが、利用可能な代替案は多くなっています。
技術レベルでの決断数は同じですが、RESTful Webサービス構築時に検討する代替案の方が少なくなっています。
具体的には、以下の事柄を立証した。
したがって、こうして量的見地から、認知されているRESTの単純性を解釈できます。
［しかしながら］、私たちの経験からすると、RESTfulサービスで非常に容易に下すことの出来る決定の中には、かなりの開発努力を必要としたり、技術的リスクをもたらしたりするものがあり、その例として、リソースの正確な仕様とそのURIアドレス方式の設計が挙げられます。
著者は次のように結論づけている。
…Web上の戦術的な、その場限りの統合を行う場合はRESTfulサービスを使い（マッシュアップ式）、高度なQoS要件のある、より長寿命の専門的な企業アプリケーションの統合シナリオでは、WS-＊ Webサービスを選択しましょう。
原文はこちらです：