 |
||||||||||||||||||
|
||||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||||
|
||||||||||||||||||
| ESBに求められるデータの違いを吸収する機能 | ||||||||||||||||||
|
「第3回：ESBにおけるデータ変換（前編）」では、ESBに求められるアプリケーション間のデータの違いを吸収する機能の一例として、XMLデータを用いた方法とその問題点について解説しました。 今回は引き続き、アプリケーション統合の際に発生する課題である「アプリケーション間のデータの違い」について、特にXML変換では対処できないケースを取り上げます。 |
||||||||||||||||||
| XML変換ではカバーできないシンタックスの違い | ||||||||||||||||||
|
多くのESB製品には前述のようにXML変換機能が備わっています。いうまでもありませんが、このXML変換機能はアプリケーションがXMLをサポートしていることを前提としています。 しかしながら、実際の現場ではしばしばXMLをサポートしていないアプリケーションを統合するケースが発生します。以下は、非XMLデータ形式の例です。
表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 次のページ |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
-
-
連載
