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




