 |
|
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製品の国内市場への普及に専心している。
|
|
|
|