SOAでエンタープライズ・マッシュアップを！

マッシュアップの真価を引き出し、Web2.0時代の“勝ち組”を目指せ

（2007年03月16日）

マッシュアップへの備えは万端か

　いまや、マッシュアップ可能なサービスやコンテンツはものすごい勢いで増え続けており、Web上に氾濫している。ブロードバンドの接続コストさえ支払えば、そうした資源を自由に利用できるわけだが、だからといって、それだけで十分だというわけではない。企業がブラウザの先のマッシュアップを活用するに際しては、それなりの準備が必要なのだ。

　では、どんな準備が必要かと言えば、ここでのベスト・アプローチは、マッシュアップを前提としてSOAを設計・導入するというものだ。言いかえれば、会社のシステムをファイアウォールの外のサービスやアプリケーションに露出できるようにする、あるいは、そうしたサービスやアプリケーションを利用できるようにする──のである。もっとも、これは、実際にはかなりハードな作業になる。というのも、おそらく会社の現行システムは、ファイアウォールの中に閉じ込められており、オペレーティング・システムの外を認識することはできないはずだからだ。

　Webベースのサービスやコンテンツをマッシュアップのリソースとして活用したい場合には、まず、ファイアウォールの内側と外側のシステムでマッシュアップしようと思うサービスのカタログを作成し、テストを行うことになる（この際、セキュリティ対策についても検討を加える）。

　マッシュアップへの取り組みは、「要求仕様」「設計」「ガバナンス」「セキュリティ」「デプロイメント」「テスト」の6つのステップから成る。この6ステップは、マッシュアップにたどり着くために、どれ1つとして欠かすことのできない基本的なアプローチである。以下、それぞれのステップについて、詳しく見ていくことにしたい。

　会社特有のニーズに合わせるためには、マッシュアップにおいても（第1のステップである）要求仕様書が必要になる。ここで、よく犯しがちなミスは、雑誌の情報などを鵜呑みにして、他社で有効に機能しているのであれば自社でも大丈夫だろうと安易に考えてしまうことだ。実際には、それよりもむしろ、自社固有のビジネス・ドライバや現行アーキテクチャの状況などを考慮することのほうが重要なのである。まずは、どのマッシュアップが有益か、それを実現するためには何をするべきなのか、という点からスタートする必要があるわけだ。

　第2のステップであるマッシュアップの設計では、最適なSOAベースのマッシュアップ・プラットフォームを構築するために、システムをどのように構成するか、どの技術や標準を採用すべきか、といったことを検討することになる。ここでは、次のような点への注意が必要だ。

　「どのインタフェースをどのように露出させるか」「拡張性をどのように確保するか」「ビジュアル型と非ビジュアル型マッシュアップに、それぞれどうアプローチするか」「Web上のサービスやインタフェースをどのように活用するか」「自社のインタフェースやサービスの露出をどう管理するか」

　第3のステップとなるガバナンス（設計時とランタイム時のポリシーの設定と強制）も、マッシュアップにとってはやっかいな問題である。マッシュアップはいくつかのサービスで構成されるだけでなく、それ自体がサービスとして機能することを考えると、SOAに含まれる他のサービスやプロセスと同様、サービスのライフサイクル全般にわたって管理する必要がある。なかでも、マッシュアップを認識するレジストリ／リポジトリの選択／構築／保守が重要となる。なお、マッシュアップを管理することも重要ではあるが、その前段階として、ポリシーとプロシージャによってマッシュアップの過剰な増殖を抑えることも忘れてはならない。

　マッシュアップでは、第4のステップであるセキュリティにはとりわけ大きな注意を払わなければならない。何しろ、自社で開発したものでも所有しているものでもないインタフェースやコンテンツ、サービスを活用しようというのであるから、いくら注意しても、注意しすぎるということはないのである。

　一見なんでもないAjaxマッシュアップが、実は顧客データをどこかのリモート・サーバに転送し、会社の事業を窮地に陥れるものだった──などという悪夢を想像していただければ、マッシュアップ・プラットフォームの安全性を確保するためには、セキュリティ・ポリシーと技術レイヤの実装が不可欠だということもご理解いただけよう。なお、もちろんそれは、SOAセキュリティに連動可能、あるいは統合可能なものでなければならない。

　マッシュアップの第5のステップ──デプロイメントを適切に行うためには、最適な技術と標準を選択する必要がある。インタフェースとしてはAjaxの人気が高いが、そのほかにもAdobe Flexなどが存在する。その中からどれを選択するかは、何を開発する必要があるのか、あるいは開発者が何を重視しているかによって決まる。さらに、選択した技術がガバナンスやセキュリティにどのようにリンクするかについても考慮しなければならない。具体的には、「SOAでマッシュアップをサポートするのに不可欠な製品は何か」「現在実装されている技術ソリューションと、どのようにリンクするか」といったことについて考える必要があるわけだ。

　最後に（第6のステップとして）、あらゆる側面から利用パターンを検討して、それを基にテスト計画を立てることになる。もちろん、SOAと外部の“マッシュ可能な”コンポーネントの相性はどうか、あるいは採用した技術と標準は期待どおりに機能しているかといった点もチェックしなければならない。また、テスト計画は、設計、ガバナンス、そしてセキュリティとも密接にリンクしている必要がある。基本的には、サポートするすべてのコンポーネントとともに開発プラットフォームをテストすることになるわけだ。

あらゆるビジネス要求に対応可能

　マッシュアップとSOAは、いわば“連続体”である。既存の情報やサービスにWeb 2.0の新しいコンポーネントをリンクしてサービスを構築するマッシュアップは、シンプルなビジネス問題の多くを手早く解決できる便利な手法として、最近、急速に普及しつつある。しかも、うまく拡張すれば、将来的には、より複雑で困難な問題も解決できるようになるはずだ。それにつれて、SOAの価値も今以上に認知されることになろう。

　新しいコンセプトが登場したとき、企業はそれぞれのニーズに合わせて、そのコンセプトをローカライズすることになる。フリーサイズのソリューションはまず存在しないからだ。だが、SOAとマッシュアップには、正しい基盤さえ整えてやれば、ほとんどあらゆるビジネス要求に対応することができるという利点がある。しかも、もし、要求が変化したときには、カードを手もとにかき集めて再びシャッフルしてやればよいのである。こんな便利なコンセプトが普及しないわけがない。

(Computerworld.jp)

前のページへ < ｜1｜2｜3｜