TOP
＞
業務システム
＞ ESBに求められるデータの違いを吸収する機能
SOA/ESBの真の姿とは
第４回：ESBにおけるデータ変換（後編）
著者：
Fiorano Software 青島 茂
2007/9/3
1
2
3
次のページ
ESBに求められるデータの違いを吸収する機能
「
第3回：ESBにおけるデータ変換（前編）
」では、ESBに求められるアプリケーション間のデータの違いを吸収する機能の一例として、XMLデータを用いた方法とその問題点について解説しました。
今回は引き続き、アプリケーション統合の際に発生する課題である「アプリケーション間のデータの違い」について、特にXML変換では対処できないケースを取り上げます。
XML変換ではカバーできないシンタックスの違い
多くのESB製品には前述のようにXML変換機能が備わっています。いうまでもありませんが、このXML変換機能はアプリケーションがXMLをサポートしていることを前提としています。
しかしながら、実際の現場ではしばしばXMLをサポートしていないアプリケーションを統合するケースが発生します。以下は、非XMLデータ形式の例です。
プレーンテキスト（フラットファイル）
EDI形式（X.1.2 EDI、EDIFACTなど）
メール形式
CSV
ERP固有の形式（SAP-IDOCなど）
SQLのクエリ結果
表1：非XMLデータ形式の例
これらに対する解法は、各種データ形式からXMLに（およびその逆へ）変換する機能をESBに設けることです。
また別の問題として、文字コードがアプリケーション間で異なっている場合があげられます。例えば、Windows上のアプリケーションから送られるShift-JISのデータを、EUCをベースとしているSolaris上のアプリケーションが受信したとしても、Solaris側では理解できません。
このため、文字コードの違いもESBで吸収してやる必要があります。ただこの問題は日本特有のもので、外国製のESB製品ではあまり考慮されていないようです。
シンタックス変換機能を追加したESB
ESBが備えるべきデータ変換機能はXSLTによるXML変換機能で充分とする製品も存在します。しかし既存アプリケーションの再利用を促し、迅速にアプリケーションを統合することを目的とするSOAにとって、シンタックスの違いを吸収・変換する機能をESBが備えていることは不可欠です。
シンタックス変換機能を追加したESBのフローは図1のようになります。
図1：データ変換のプロセスフロー
（画像をクリックすると別ウィンドウに拡大図を表示します）
大切な点は、XML変換機能やシンタックス変換機能が固定されているのではなく、ユーザが状況に応じて自由にその実行順序を変えられることです。
もっとも効果的な方法は、各種の変換機能をそれぞれコンポーネントとして提供し、必要なコンポーネントをESB上に任意の順序で並べられるようにすることです。つまりデータ変換のためのプロセスフローをESB上に組み立てられるということになります。
これは、まさにデータがバス上を流れ、流れている間に必要なデータ変換が適用されるという、バス形式のESBに適した処理方法といえるでしょう。
1
2
3
次のページ
著者プロフィール
Fiorano Software, Inc.
日本オフィス ジャパン オペレーション マネージャ
青島 茂
SOA/ESBの分野に2003年1月からたずさわる。2005年3月にFiorano Softwareの日本オフィスを開設し、現在SOA/ESB製品の国内市場への普及に専心している。
INDEX
第4回：ESBにおけるデータ変換（後編）
ESBに求められるデータの違いを吸収する機能
マッピングツールでは解消できないセマンティクスの違い
ESBに求められるデータ変換機能のまとめ
