TOP＞業務システム＞ 1対1もしくは1対nのパターン
SOA/ESB
SOA/ESBの真の姿とは

第２回：ESBからSOAを理解する
著者：Fiorano Software  青島 茂   2007/5/15
前のページ  1  2  3  次のページ
1対1もしくは1対nのパターン

   統合パターンが1対1もしくは1対nの統合が、もっともプリミティブなものです。このタイプの典型的な例は、アプリケーション間でデータの整合性を維持する目的で実施するデータ統合です。

   同じ対象を指すデータを複数のアプリケーションで保持しているようなケース（例えば、顧客住所を本社の請求書発行システムと支店の販売支援システムでそれぞれ保持しているような場合）では、両者の間でデータの整合性を維持することが常に問題となります。

   このような場合、一方のアプリケーションでデータ変更や新規追加を行うと他方のアプリケーションにも変更／追加データを送って、整合性を維持します。これらのアプリケーションは1対1または1対nの関係にあります。

   データの整合性に限らず、その他の多くの目的で、この1対1もしくは1対nの統合は実施されてきています。そのための技術やミドルウェアにも多種多様なものが登場し、採用されてきました。
  • RPC、JavaのRMI、DCOM、CORBAといった分散プログラミング技術
  • FTP
  • EDI
  • MOM（MQ、JMSなどによるメッセージングミドルウェア）
  • J2EEベースのアプリケーションサーバ
  • その他

表2：アプリケーション間を統合するために利用されてきた技術n

   表2にあげたものは、1対1もしくは1対nの関係にあるアプリケーション間を統合するために利用されてきた技術であり、現在も多くのユーザに利用されています。議論を進めるにあたって、MQもしくはJMSに代表されるメッセージングミドルウェア（MOM）を例にとることにします（図2）。

1対nのインテグレーション例（MQの場合）
図2：1対nのインテグレーション例（MQの場合）

   MOMを用いたアプリケーション統合は、当然のことながらアプリケーション間でメッセージのやり取りを実現しています。アプリケーションはMOM製品に固有のプロトコルを介してメッセージを送受信します。つまりメッセージの送り側も受け取り側も、MOM製品固有のプロトコルをサポートしなければなりません。

   J2EEにおけるメッセージングの標準規格であるJMS（Javaメッセージサービス）を用いる場合でも、事情はまったく同じです。各アプリケーションは、JMSによるメッセージ送受信を行えるようにプログラミングしておかなければなりません。

   このことはMOMに限ったことではありません。EDIやFTP、EJBなども各アプリケーションは使用されている統合技術のプロトコルをサポートするように構築しなければなりません。

   しかしながら、単一の技術や標準規格で簡潔にいかないのが実世界のビジネスです。では変更要求が発生した場面を考えてみましょう。
変更要求の発生（アプリケーションの置き換えのケース）

   「受注管理アプリケーション」から受注データをMOMを介して「顧客管理アプリケーション」に送信し、顧客の注文履歴の管理や購買動向の分析に利用していると仮定します。MOMで採用されているプロトコルがJMSでもベンダー独自のMQプロトコルでも事情は同じなのですが、ここではMQ製品の固有のプロトコルとしておきます。現行のシステムでは、両アプリケーションとも自社内で運用しています。

   ある時、経営サイドから運用コストの低減を理由に、顧客管理アプリケーションをASPベンダーのCRMシステムに切り替えるという決定が下されたとします。このASPベンダーは、CRMシステムへのアクセスにWebサービスを用意していますが、このままではうまく統合することができません。この場合、どうすればいいのでしょうか。

変更要求
図3：変更要求

   いろいろな解決方法が考えられますが、図4に示すようにメッセージングミドルウェアの上位にプロトコルの違いを吸収する「プロトコル変換機能」を持たせることが、おそらくもっとも効果的な方法でしょう。

プロトコル変換機能の追加
図4：プロトコル変換機能の追加

   そしてこの段階で、さらに「受注管理アプリケーション」をERPで置き換える決定がなされたとしましょう。このERPは外部アプリケーションへデータを送信するためのプロトコルとして、MQではなくJMSを提供しています。これらは同じようなメッセージング用プロトコルですが、そのままではつながりません。そのため図5の解決策を採用します。

プロトコル変換機能の追加
図5：プロトコル変換機能の追加

   図5は旧EAI製品を図式化したものと非常によく似ています（中央のMQサーバをEAIのブローカーと置き換えて図を見てください）。旧EAIでは、プロトコル変換の機能を別売りのアダプタとして提供していました。

   このアダプタが高価なものである上に、アプリケーションの種類もしくはプロトコルごとに何種類も購入する必要がありました。このことが、旧EAI製品が成功しなかった一因ともなりました。

   ここで図中の2つのプロトコル変換機能を1つに繋げてみてください。何かESB風に見えてきませんか。
前のページ  1  2  3  次のページ

Fiorano Software, Inc. 日本オフィス ジャパン オペレーション マネージャ 青島 茂
 著者プロフィール
Fiorano Software, Inc.
日本オフィス ジャパン オペレーション マネージャ
青島 茂
 SOA/ESBの分野に2003年1月からたずさわる。2005年3月にFiorano Softwareの日本オフィスを開設し、現在SOA/ESB製品の国内市場への普及に専心している。
INDEX
第2回：ESBからSOAを理解する
  はじめに
1対1もしくは1対nのパターン
  ESBの機能1（コネクティビティの提供）