【 ここから本文 】
- TOP
- > Topics : CRM
- >
CRM
ソーシャルブックマークに登録 ：
印刷用ページの表示
SOAの「現実解」を探る──ベンダー各社のコンセプトや実装技術を徹底比較
注目のコンセプト、第2フェーズに突入。ユーザー企業はどう準備すべきか
（2006年02月23日）
SOAは実現可能か
筆者はここまで「SOAとは何か」という明確な定義をせずに、SOA対応を打ち出しているベンダーと製品を紹介してきた。では、「前述の製品によってSOAが実現できるのか」と問われれば、それに対して否定も肯定もできない。
例えばBEAシステムズが言うように、開発方法論としてのSOAならば、確かに同社の提供する製品群でSOAは実現できるだろう。また、既存の資産を生かして新しいビジネス・プロセスを柔軟かつ迅速に実現したいのであれば、EAI/BPMやアプリケーション系のアプローチからSOAを考えるのが得策と言える。つまりSOAに何を期待するかで、「実現できるかどうか」の答えも変わってくる。
最後に、これまで説明してきたベンダーの主張に沿って、SOAのメリットを3つの観点からまとめておこう。
1. インフラとしてのSOA
- システム機能の再利用が容易になり、開発工数が削減される
- 疎結合による柔軟な連携技術を用いることで、システムの変更・追加が容易になる
2. 開発技術としてのSOA
- 既存のIT資産を活用したビジネス・プロセスの迅速化が可能になる
- ESBなど新しいアーキテクチャを取り込むことにより、柔軟なシステム連携や連携時のボトルネック解消が可能になる
3. ビジネス・プロセス抽象化レイヤとしてのSOA
- 既存のIT資産を活用したビジネス・プロセスの構築が可能になる
こうしてメリットを並べてみると、ベンダーごとに少しずつSOAの定義が違うとはいえ、各社の目指す方向はほぼ同じだということが見えてくる。仮にSOAという言葉がなくなったとしても、「柔軟なシステム・アーキテクチャの下で、複数の機能を連携させて新しいビジネス・プロセスを迅速に実現する」ということを目指していることに変わりはないのだ。これから技術もアーキテクチャもどんどん進化を重ねるだろうし、そうした意味では「現段階で利用できる技術、製品を用いて実現するのがSOAなのだ」という結論が現実解と言えるだろう。
SOA導入事例 2──米国ガーディアン生命
アプリケーションの再利用で、開発コストを30％削減
ガレン・グルマン／InfoWorld米国版
ニューヨークに本社を置く米国ガーディアン生命は、同社の社内システムを根本から見直すことを決定した。無秩序に開発、拡張を続けてきた結果、今や同社の業務システムはITスタッフの手に負えないほど複雑なものとなってしまったためだ。同社のチーフ・アーキテクト、ジェイム・スグエラ氏は、「これまではアプリケーションを構築したり、接続したりするための標準的な方法もなければ、それらを再利用するという考えもまったくなかった」と語る。
そこで同社は、システムの再構築を実施するにあたり、SOAのアーキテクチャを取り入れることにした。「異なる技術によって開発された複数のシステムを連携させるためには、SOAに基づいたシステムの再構築がベストだった」と、スグエラ氏はその理由を説明する。そうして構築された新システムが図Bである。
| 図B：米国ガーディアン生命のシステム概要図 |
 |
新システムの中核を成すのは、J2EEのワークフローと外部接続用のミドルウェアを統合した「エンタープライズ・サービス・マネジャ」と、各システムからのリクエストを管理するためのメッセージング・ミドルウェア「WebSphere MQ」である。これらのシステムがどのような処理を行っているのかを以下に説明する。
まず、処理の実行を依頼するリクエストが、CRMシステム、同社の代理店と顧客が利用するWebポータル、顧客が使う電話システムの3種類のクライアント・システムから送られてくる。エンタープライズ・サービス・マネジャは、どのサービスをどういう順序で呼び出すのか、そしてどのようなデータ・リソースが必要かを判断し、サービス化された各アプリケーションと連携して処理を実行する。一連のトランザクションの終了時には、クライアントは要求した結果、もしくはエラー・メッセージを受け取るようになっている。
また、同社では、代理店に対して保険請求/保険契約者管理/保険金給付の3つのシステムを提供しているが、代理店のシステムとこれらのシステムとの接続に際して、Webサービスを利用することにした。社内外の顧客に単一のコミュニケーション・システムでサービスを届けるには、Webベースのインタフェースが必要だったためだ。
ガーディアンは膨大な数のメインフレーム・プログラムを使っており、同社はそれらのプログラムもサービスとして使えるよう検討を重ねていたが、ここで問題が発生した。サービス間でサービス・リクエストを変換する際に、同社はWSTL（WebService Transaction Language）を使っていたが、メインフレーム上で稼働しているプログラムの中には、WSTLをサポートしないものがあったためだ。そこで同社は、WSTLをサポートするため、該当するプログラムのコードを修正するのではなく、EJBを使用して再変換を行うことにした。
上述したようなSOAベースのアプローチにより、アプリケーションの開発にかかるコストを、従来と比較して30％程度節約できたとスグエラ氏は見積もっている。
スグエラ氏は、SOAに基づいた形でアプリケーションを開発するためには、アプリケーション開発の考え方を根本から変える必要があると言う。「これまで築いてきた文化をまったく変えるものだということをあらかじめ知っておくべきだ。さして難しくはないだろうと甘く考えてはいけない」
