SOAの導入を成功させるための10のステップ――SOA導入プロジェクトの経験者から聞き出した秘訣を一挙公開 2ページ

[IDG-2007/08/09]
シェア

STEP 3
再利用できるものを慎重に選別する

　SOAを導入する際には、既存のデータ・ソースとアプリケーションの中で再利用できるもの注意深くえり分け、できるかぎり既存の環境を引き継ぐ方法を模索することが望ましい。ただし、将来的な相互運用性や拡張性を損なうような慣例やテクノロジーに縛られないように注意しなければならない。

　既存環境の調査を行う際には、まず、データ・ソースとアプリケーションのリストを作成する。もちろん、自社のファイアウォールの外に存在するパートナー企業が提供しているサービスについてもリストアップする必要がある。

　次に、既存環境の中で、SOA環境に移行したあとも重要な役割を担うことになるデータやアプリケーションを選別する。これは、大変な作業であるが、全社的なSOAの導入を目標とするのであれば、避けることはできない。ただし、必ずしも最初のサービス構築を開始する前に終える必要があるわけではない。

　また、SOAを導入するためのテクノロジーやツールとしては、サービスの開発／配置を行うツール、サービスの情報を公開するレジストリ／リポジトリ、サービスやアプリケーション間の通信を行うメッセージング・インフラ、サービスを自在に組み合わせる手段、アプリケーション間のメッセージ・フォーマットの変換を行う仲介機能を備えたサービス管理ツールなどが必要になる。さらに、将来的には、アプリケーション層のネットワーク機能やBPM（ビジネス・プロセス管理）、BAM（ビジネス・アクティビティ・モニタリング）などのアプリケーションも絡んでくることになるだろう。

　このように、SOA環境を構築するためのテクノロジーやツールは数多く存在するが、この時点ではどれを導入するかについて、難しく考えてもしかたがない。なぜなら、ロッキード・マーティンのヴィバート氏が、「メタデータを作成する作業は大変な労力が必要で、同じデータに対して15回行えば、15通りの異なるメタデータの定義が出来上がってしまうほどだ」と指摘するように、既存環境に蓄えられたデータにメタデータを付ける作業だけで、おそらく手一杯になるからだ。

STEP 4
最初のサービス構築に挑戦する

　システム構築の実作業に移る際には、ホワイトボードに書き出した多数の計画の中から比較的小規模なものを1つ選び、試験導入に取り組むべきである。この作業は次のような流れになる。まず、その計画に関連するアプリケーションの中で、重複している機能を特定する。そして、新たに構築するサービスの仕様と開発者、使用するツールを決定し、サービスの開発／配置を開始する。最後に、新しく構築したサービスを呼び出すように、既存のアプリケーションに変更を加えるという手順になる。

　新たに構築するサービスには、再利用性がある、結合が緩やか（疎結合）、ステートレス（クライアントの状態を保持しない）、他のサービスやアプリケーションから発見可能といった特性を持たせることが望ましい。なお、サービスは、ビジネス・プロセスの1プロセスにマッピングされるべきである。なぜなら、再利用性を高めることと、他のサービスとの機能の重複を回避することにつながるからである。

　 H＆Rブロックのトンプソン氏は、「SOAの導入に始めて取り組んだ際に、ビジネス・プロセスよりもオブジェクト層の観点からサービスを設計してしまい、結果として期待していたほどの再利用性が得られなかった。そのため、多くのサービスを設計し直さなければならなくなった」と語る。

　サービスは、相互運用性を確保するために標準化されたWebサービスの仕様に基づいて構築されるため、再利用性が高い。ただし、JMS（Java Message Service）のように、Webサービスの仕様に含まれないものを用いて外部と通信を行う場合もある。

　では、サービスが用いる通信方式は、どのような基準で決定するべきなのだろうか。ロッキード・マーティンのヴィバート氏は、「送受信するメッセージのデータ・サイズが比較的小さい場合や、レスポンス・タイムに関する要件が厳しくない用途であれば、Webサービスの仕様が最も適している。しかし、大容量のデータを送受信する場合や迅速なレスポンスが求められる用途では、JMSのようなバイナリ・プロトコルで通信を行うべきだ」と助言する。

　Webサービスには相互運用性が備わっているため、開発者は基本的に任意のツールやプラットフォームを用いてサービスの開発／配置を行うことが可能である。オープンソースのレジストリを開発している米国フラッシュラインのCEO（最高経営責任者）、チャールズ・スタック氏は、「ツールやプラットフォームを決めることが、従来ほど重大な検討事項ではなくなることも、SOAがもたらすメリットの1つである。Webサービスは、インフラ・レベルで抽象化されるので、これまでのアーキテクチャと比べてプラットフォームに依存することが少ない。そのため、アーキテクチャ全体に影響を及ぼすことなくプラットフォームを変更できるのだ」と語る。