Jonathan Mack氏(リンク)によると、SOAの導入は「こんにちのアナリスト機関やwebinarパブリッシャーが提案しているほど、ユビキタスではない」。その理由は非常に単純である。SOAの実装を成功させるのは、極めて難しいからである。Jonathan氏がまとめた、主な課題は以下のとおりである。
- Pre-SOAアーキテクチャの処理 - 既存のエンタープライズアセットをSOAの実装に統合する
- SOAを企業に売却 - SOAがその価格を正当化するほどの利益を産出するという(一般的な内容ではなく)具体的な事実を交えて、ビジネス関係者を納得させる
- SOAへの最も効果的なロードマップの開発 - SOA構想を実現するプロセスを定義する
SOA実行者の大半が、すでに利用可能な機能をできる限り多く再利用することで、既存のエンタープライズアプリケーション上のシンレイヤーとしてサービスを構築することを唱えている一方、そうした実装は一般に考えられているよりも困難であることが多い。Jonathan氏は以下のように指摘している。
レガシーシステムはバッチのフラグメントとして、また意味のあるビジネス機能を生み出すために、具体的なシーケンスで結合されなければならないオンライン ステップとしてビルドされる。レガシーステップは、プラグマティクスの要求を満たすように意図されており、個々の機能へのマッピングではなく開発プロセス の実用性によって推進されることが多い。各ステップは、サービスパースペクティブからの意味や一貫性が不足している。
Jonathan氏がまとめた、この問題に対する現実的なアプローチは以下のとおりである。
- 構築しようとするサービスに対して、オンランプ/オフランプになるように、シンサービス層を構築する。たとえば、明確に定義されたインプットやアウトプッ トでプログラムを設計するといっレガシープログラマーが常日頃からおこなってきたことを可能にするコンポーネントを作成する。またそれは自分のサービスレ イヤーに簡単に接続することができる。
- 始めからモニタリングおよび例外処理フックをサービス層に組み込む。SOAのもっとも重要なメリットの1つは、アプリケーションの動作を正確にモニターする機能である。
- point-to-point 対話を通じたサービスでの明確なメリットが期待できる、具体的なサービスを構築する。サービスとして新たなコンポーネントを構築する際の明瞭な基準を定義し、公開する。主要な基準は、サービスの複数のクライアントの存在である。
- Centers of Excellenceでやり過ぎないこと。具体的に自身の環境における他のデベロッパと協働する能力ごとに選出された、小さいチームを形成する。サービス レイヤーの基礎となる共通のサービスを構築するために、始めから協同的に作業する。
- 可能な限り、メインフレームと直接対話するように自動サービスを構築し、ESBソフトウェアを使用して複合サービスを構築する。自動サービスレイヤーと複合サービスレイヤーは別々にしておく。
SOAの一般的な強みは、再使用可能性である。あいにく、これは事実に基づく議論というより感情的な議論であることが多い。この議論を支持するデータは、ほとんどない。Jonathan氏によると、以下のとおりである。
主要な関係者を納得させるために、さらに明確にする必要がある。絡み合ったシステムのねずみの巣をSOAが解決する様子を描くのはすばらしいことだが、ビ ジネス関係者はどのようにしてこの取り組みがSOAの価格を正当化するような利点を生み出すのか、詳しい説明を求めている。またROI評価において、ハー ドとソフトの数字を精選するのが得意である。SOAへのアプローチ法に関係なく、まじめに受け止められたいのであれば、非常に現実的な数字を示す必要があ る。
SOAロードマップと言えば、近ごろ最もよく知られているSOA実装のアプローチが出現した。
- エンタープライズ(トップダウン)SOAアプローチ。極めてリスクが高いアプローチであり、初期の価格は数百万ドルだった。また、サイズや複雑度に基づき、そうしたプロジェクトは正確に評価されないと言ってもいいくらいである。
- 草の根(ボトムアップ)SOAアプローチ - ビジネス主導のIT事業として、SOAのエレメントを実装する(サービスおよびインフラ)。一般的に、このアプローチは成功しない(参考記事)。一方において結果とし て生じるサービスのスコープは、具体的なビジネス課題に制限され、他の企業には適用することができない(もっと言えば、誤りである)場合がある。他方にお いては、SOAレイヤーの構築に要する時間と費用が、プロジェクトのその他のビジネスニーズを損なうこともあり得る。
Jonathan氏によって提案されている代替アプローチは以下のとおりである。
...付加的にSOAを構築する。たいていのベンダーは、これがもっとも妥当なアプローチだという結論に至る。そうは言うものの、遂行するのは単純ではな い。Enterprise Server Bus (ESB)の主要要素 - 1つのシステムから別のシステムへ情報を翻訳したり、変換したりする機能およびメッセージをルーティングする機能の他に、情報を送信するメッセージングイ ンフラが始めから整備されていなければならない。ロギング、モニタリングおよび例外処理などの共通(共用)サービスも、第1日目に実装するべきである。
IT業界をとりまくSOAの興奮が約10年続いた後でさえも、そのトータル的な複雑さから、実装を成功に導く保証されたソリューション はない。すべての新しいSOAプロジェクトには「現実主義という明確な感覚を持って取り組み、成功を叶えるために必要な過程とコストを十分研究し、理解することが必要である」。
原文はこちらです：http://www.infoq.com/news/2008/09/Unfinished-Stories