 |
|
|
| 前のページ 1 2 3 次のページ
|
|
| マッピングツールでは解消できないセマンティクスの違い
|
さて、アプリケーション統合におけるデータの違いに関する最大の問題は、今までに説明してきたXML間のマッピングツールによるデータ変換やシンタックス変換だけでは解消できない、セマンティクス上のやっかいな相違が存在することです。
このセマンティクス上の問題には多種多様なものがあり、どこまで対処可能かはESB製品やベンダーの考え方によっても異なります。またESBなどのミドルウェアの範疇の外で、ITシステム全体を通じたデータアーキテクチャとして解決すべき問題もあります。
では実際に、いくつかの例をあげてみましょう。
|
| コード体系の相違
|
例えば、図2のようなIDや製品番号のデータ値のセマンティクス変換は、両方のアプリケーションが同じコード体系で稼動しているという大前提のもとで、はじめて可能なものとなります。
図2：XML変換（再掲） （画像をクリックすると別ウィンドウに拡大図を表示します）
コード体系の異なるアプリケーションに、顧客IDや製品番号などのコード化されたデータを送っても無意味です。しかしながら、SOAではコード体系を共有しない既存アプリケーションや取引先企業のアプリケーションとも連携することが求められます。このあたりが、コード体系も事前にきちんと定義していた従来のEDIによる取引先連携ともっとも異なる点です。
コード体系の異なるアプリケーションを統合するためには、相手側のコード体系に合うようコード変換を行ったり、顧客マスターを参照して顧客IDコードを氏名などのコード化されていないデータに変換してから送信するといった処置が必要になります。
具体的にはデータ変換プロセスの一環として、マスターデータを収めたデータベースへのアクセスやコード変換を行うアプリケーションの呼び出しなどの機能をESBに組み込めるようにすることです。
図3：マスターデータの参照、コード変換アプリケーションの呼び出し （画像をクリックすると別ウィンドウに拡大図を表示します）
|
| セマンティクス上のデータの粒度（大きさ）の違い
|
「粒度」というあやふやな言葉を持ち出してしまいましたが、アプリケーション間ではその処理対象の大きさが異なるケースがあります。
|
| 例1：注文伝票の明細行
|
1枚の注文伝票に明細行を10行まで載せることが許されているアプリケーションでは、10種類の製品の注文を1枚の伝票で処理することができます。
一方、1枚の伝票で1製品の注文しか扱えないアプリケーションでは、10明細行の伝票を処理できません。
この2つのアプリケーションを統合する場合、伝票形式の違いをESBで吸収する必要が生じますが、XSLTによるXML変換では対処できません。解消法の1つは、図4のようにESB上にデータの分割機能を持たせることです。XMLデータの分割としたのは、XML処理の関連技術を使えるので扱いやすいものとなるからです。
図4：データの分割 （画像をクリックすると別ウィンドウに拡大図を表示します）
|
| 例2：ESBでは変換不可能なケース
|
ある企業の営業部門では、CRMを用いて顧客企業の管理をしていたとします。営業マンが顧客企業からの注文を受けると、CRMにその注文を登録します。きめ細かなサービスを顧客に提供するため、注文は顧客企業の部門単位で受け付けていたとします。
一方で顧客への請求書の発行は、経理部の別のアプリケーションが担っています。この請求書発行アプリケーションでは、顧客は企業単位で扱っており、顧客企業の部門別に請求書を発行することができません。
このような状況でCRMと請求書発行アプリケーションを統合し、注文受付から請求書発行までの処理を自動化しようとする場合、どのようにしたらよいでしょう。明らかにこれは、ESBなどのミドルウェアの範疇を超えた問題です。
顧客を企業単位で捉えるか、それとも顧客企業の部門単位で捉えるのか、これはまさにITシステムを離れて決定すべき業務上の問題であり、またそれに基づくデータアーキテクチャの問題です。
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
Fiorano Software, Inc.
日本オフィス ジャパン オペレーション マネージャ
青島 茂
SOA/ESBの分野に2003年1月からたずさわる。2005年3月にFiorano Softwareの日本オフィスを開設し、現在SOA/ESB製品の国内市場への普及に専心している。
|
|
|
|
|
|
