第 8 章 統合の最良事例

この章の目的は、WebSphere Product Center インプリメンテーションの統合の最良事例を要約することです。これらの最良事例を使用することは、高品質で信頼性の高いシステム間の統合を達成するのに役立ちます。統合のすべての局面を扱うために、本書は、統合の異なる局面のいずれかに関連した最良事例を識別するために開発されました。

統合のかぎとなる要素には以下のものがあります。


定義および頭字語

統合の各次元: 下にリストされている次元を使用して、WebSphere Product Center インプリメンテーションにあるさまざまな種類のインプリメンテーションを理解することができます。本書の残りの部分では、それぞれの最良事例やガイドラインが適している次元やインプリメンテーションの種類に焦点を当てます。

ソース・システムまたはターゲット・システムとしての WebSphere Product Center

最も明確な次元は、WebSphere Product Center がソース・システムであるか、 情報を交換するためのターゲット・システムであるかということです。ソース・システムはその制約を統合に適用しますが、 それに関して最も重要なのは、(a) デルタ・シンジケートを実行する能力、 (b) 統合を開始する能力、(c) データ送信の成功または失敗に関する通知を受け取り、 適切なアクションを実行する能力、(d) サポートされるプロトコルおよび形式、さらに EAI インフラストラクチャーのサポート、といった点などです。

システムの制御

ここでは、制御システムを、統合の内部トリガーに応じてアクションを実行するシステムとして定義しています。1 つの例では、WebSphere Product Center がシンジケートをジョブとしてスケジュールに従って実行します。別の例では、アイテムを追加すると、SAP が WBI アダプターをトリガーします。WebSphere Product Center が統合のためのソース・システムになるか、あるいはターゲット・システムになるかは、統合においてどのシステムが制御システムになるかに完全に依存しています。いくつかのケースが考えられます。FTP サーバーや EAI ツールなどの仲介者が関係している場合、ソース・システムとターゲット・システムの両方が制御システムになる可能性があります。レガシー・システムがスケジュールに従ってファイルを FTP サーバーに置きます。一方、WebSphere Product Center はスケジュールに従ってファイルを選択します。WebSphere Product Center が制御された宛先システムになる (つまり、データのインポートをトリガーする外部のものを待機する) 例では、IBM WBI は、たとえば Transora からアイテムを更新するというメッセージの内容とともに WebSphere Product Center に起動側を経由してメッセージをポストします。WebSphere Product Center が制御されたソース・システムになる (つまり、データのエクスポートをトリガーする外部のものを待機する) 例では、IBM WBI は WebSphere Product Center キューを定期的にポーリングし、すでに選択されたファイルがないかどうか調べます。

プロトコル

WebSphere Product Center インプリメンテーション・チームと顧客リソースには、プロトコル、形式、およびメッセージ対ファイル・ベースの統合において多くの混乱が存在します。このため、本書の目的の 1 つは、これらの概念に関する共通のノーメンクレチャー (銘板) が確立されたことを示すことです。プロトコルの例には、ファイル転送プロトコル (FTP)、Hyper Text Transfer Protocol (HTTP)、Simple Message Transfer Protocol (SMTP、E メールなど)、Java Messaging Service (JMS)、および IBM WebSphere Message Queuing (IBM WebSphere MQ) があります。プロトコルは、エンベロープ、数値などのデータのエンコード、および予期される応答を定義しますが、転送される内容とは無関係です。すべての統合において、常に少なくとも 1 つのプロトコルがあるため、使用されるプロトコルに関しては非常にはっきりしています。さらに、統合のさまざまな段階では、実際には異なるプロトコルを使用している場合があります。SAP の WBI アダプターは、HTTP を使用して SAP から WBI Inter Connection Server (ICS) へデータを転送している可能性があります。続いて、WebSphere Product Center が MQ クライアントとして接続している別のキュー・マネージャーにそのデータが転送されるように、IBM MQ キュー・マネージャーに渡します。

形式

データがレイアウトされている形式は、プロトコルとは独立しています。形式の例には、コンマ区切り値 (CSV)、パイプ区切り、eXtensible Markup Language (XML)、あるいは、単に事前定義された幾つかのフィールドおよび電子データ交換 (EDI) メッセージなどのレコード構造があります。それぞれの形式は、ロケーション・パラメーターおよび長さパラメーター、あるいはタグを使用してフィールドを定義します。特定の形式に必要になる可能性があるエンコードについて留意することは重要です。たとえば、不等号括弧 ('<'、'>') などの文字を XML ではエスケープする必要があるということや、CSV ではコンテンツに実際にはコンマが含まれる可能性があるということは、インプリメンテーションにおいてしばしば見落とされます。

データのサイズ

この次元は、"メッセージ・ベース" の通信あるいは "ファイル・ベース" の通信と混乱してしまうことが非常に多いため、この点を正しく理解することは重要です。"メッセージ・ベース" の統合には通常、小さいデータの交換、および以下のようなプロパティーが含まれると想定されます。

ただし、ファイル・ベースまたはバッチ統合からメッセージ・ベースを区別する明確な線引きはありません。それで、混乱したり重複した次元ではなく、明確な次元のセットを定義することは重要です。こうして、データの全体のサイズは、"メッセージ・ベース" か "バッチ" 統合としてラベルが付けられるかということよりも、考慮すべき重要な次元といえます。

通信のタイプ

考慮すべき別の次元は、統合に関係する通信のタイプです。同期式通信によって、特定のアクションの結果としてユーザーまたはシステムへの直接フィードバックを提供します。たとえば、HTTP を使用して通信することによって、アクションがポストされた後にシステムまたはユーザーへの自動フィードバックが提供されます。一方、非同期式通信は、"応答不要送信" ストラテジーの多くを使用します。たとえば、その後システムによって選択される FTP サーバー上でのファイルのデポジットが、統合に関係している場合、アクションの結果のファイルをデポジットするシステムへの自動フィードバックはありません。

頻度

"データのサイズ" という次元とともに、この "頻度" という次元は、定期的に処理する必要のあるデータの合計量を捉えます。

統合スレッド

この仲介システムおよびインフラストラクチャーの次元は、EAI インフラストラクチャーを使用するかどうかを捉えます。さらに、レガシー・システムとの統合では時折、データをレガシー・システムへアップロードまたは抽出するために、仲介プログラムが書かれる可能性があります。これらの仲介システムまたはプログラムは、ほとんどの場合統合チェーンにおいて最も弱いリンクであるため、これを理解および文書化することは重要です。

特に、複数のホップが必要になる可能性のある複雑な統合 (例、WebSphere Product Center と WBI と宛先システムなど)、標準ではない方法 (データベースの直接更新など)、複数のプロトコル、あるいは他の通信方法 (ファイアウォールを介した通信など) では、早めに単一の作業スレッドまたは統合の完了パスを確立します。これによって、問題を識別し、他の関係者 (ネットワーク管理者、あるいは IBM WBI で作業するチームなど) にこれらの接続問題を並行して解決するための適切な時間を提供します。

上にリストされている統合の各次元は、WebSphere Product Center インプリメンテーションでの統合について説明する際の標準の用語になります。分析 / 設計の段階で PS チームによって提供される文書は、これらの次元を明確にまた一貫して使用する必要があります。

頭字語

頭字語

定義

EAI

エンタープライズ・アプリケーション統合

FTP

ファイル転送プロトコル

HTTP

Hyper Text Transfer Protocol

MQ

IBM のメッセージ・キューイング・ミドルウェア。すべての接続ソリューションは、現在 WebSphere ブランドの下にあるため、しばしば IBM Websphere MQ と呼ばれます。

ICS

IBM の WBI Inter Connect Server

WBI

IBM の WebSphere Business Integration スイート、IBM からの EAI スイート。


設計原則

再利用性

統合のインプリメンテーション方法の基礎となる全体的な基盤は、再利用性です。WebSphere Product Center が成長し、より多くのクライアント・インプリメンテーションが実行されるにつれて、事前に統合されていないシステムとの統合と、事前インプリメンテーションで統合されたシステムとの統合の両方をすばやくスケーリングおよび解決することが必要です。この要件を解決するには、別のクライアント用に同じシステムを統合する場合に最大の効果性をもってこれを行うことができる、という再利用性を念頭に置いてすべての統合努力を行う必要があります。

再利用性は次のように実現されます。(a) IBM WBI などの EAI ツールおよび汎用ビジネス・オブジェクトのそのモデルを利用する、(b) データ・モデルから独立した形式を選択する、(c) データ・モデルから独立し、他のインプリメンテーションで再利用できる WebSphere Product Center スクリプト (肯定応答、ポーリングなど) のライブラリーを書く。

情報の共有

統合する方法としての通信

概念上は、統合は、制御システム WebSphere Product Center および制御されるシステムとの通信によってトリガー可能な、単なる一連のイベントと見なすことができます。これらのイベントは、システム間で渡されるメッセージ、コンテンツまたはファイルをポーリングする自動処理、あるいはその他の基本的な通信方法によってトリガーできます。たとえば、通信には、加えられる変更のタイプ (追加、更新、削除)、固有の通信 ID (追跡 / 確認用)、および WebSphere Product Center 内または統合システム内のいずれかでの変更に影響する関係するコンテンツが含まれます。

信頼性の尺度

変更を通信するためにシステム間で情報を渡すことに加えて、特定のトランザクションの成功および失敗を知らせるための手段も必要です。このようなハンドシェーク通信は、通信の同期フォームを使用して最も直感的にインプリメントし、統合システムが、もう一方の終端で受信に失敗したために特定のトランザクションを再送信する必要があるかどうか追跡できるようにし、これによって統合の信頼性を向上させ、究極的に保証することができます。

情報形式

これらの通信の特定の形式は、その周囲の形式と処理機能の両方をインプリメンテーション全体で再利用できる、十分に汎用性のある仕方で設計する必要があります。

システム間の通信に使用する一般形式について考慮する場合、以下の必要に照らして形式の再利用性に注目することは重要です。

情報処理

システム間で送信される情報の形式はいくらか一般的であると考えられますが、特に WebSphere Product Center と統合システムの間の直接リンクとして統合を表示する場合、すべてのインプリメンテーションが事前定義された形式に当てはまるわけではないことを理解できます。データ・モデルなどの相違のためにインプリメンテーションごとに形式と WebSphere Product Center スペックとの間の形式およびマッピングを再度ツールにかける必要を避けるため、XML 形式と WebSphere Product Center 仕様との間で再利用可能なマッピング機能を使用することをお勧めします。

EAI プラットフォームの使用

これを行う 1 つの方法は、WBI または webMethods スーツなどの EAI プラットフォームを使用することです。これにより、再利用可能な接続の作成が可能になり、たとえば WebSphereProduct Center は、完全に再利用可能な単一の形式 (例、単一の XML DTD) を介して通信できるようになります。インプリメンテーションの詳細事項のために生じる相違点は、情報を処理する WebSphere Product Center 機能を再度ツールにかける必要なしに、WBI によって解釈することができます。WebSphere Product Center 機能を再度ツールにかける必要がなければ、同じ機能性をインプリメンテーション全体で利用することができます。

その他のオプション

しかし、考慮すべき別の点は、特定のクライアントは、企業全体を通してその他のシステムですでに使用されている形式の再利用を必要とする場合があるという点です。これにより、WebSphere Product Center がすでに存在する DTD を使用できるようにするのではなく、WebSphere Product Center が企業内のその他のシステムが理解できるように翻訳する必要のある別個の DTD を完全に導入するのは困難になります。このような場合には、WebSphere Product Center 内の仕様と DTD の間で翻訳するための再利用可能機能を使用しなければなりません。

EAI プラットフォームを使用している場合でさえ、内部 DTD への WebSphere Product Center 管理の情報のマッピングを理解するという観点からすれば、この方法が特定のクライアントに対してより有用で、より理想的な方法になる場合があります。

イベント処理

理想的には、WebSphere Product Center 内の自動処理がイベントを処理します。たとえば、WebSphere Product Center リリースで紹介されたキューイング機能を使用して、メッセージの送信 (アウトバウンド・キュー) と、応答および着信メッセージの受信 (インバウンド・キュー) の両方を処理することができます。さらに、キュー処理スクリプトを使用して、メッセージの実際の処理を扱い、実質的には、特定のメッセージの結果としてトリガーするイベントを実際に実行することができます。

ただし、イベント処理は、WebSphere Product Center の特定の機能あるいは特定のバージョンと直接結びついている必要はありません。イベントを処理するその他の方法には、FTP サーバーをポーリングする WebSphere Product Center 内のスケジュールされたジョブ、ファイルのローカル・ファイル・システムをチェックする (文書ストア経由) スケジュールされたジョブ、起動側ベースのトリガー・スクリプトがポストされた情報あるいは他の方法に基づいたイベントの起動を含めることができます。選択されるメソッドは最終的に、データのサイズと、特定の統合の頻度ディメンションの要件を注意深く考慮することに依存しています。

トラッキングの変更

システム間の完全な同期化のインプリメントを可能にするには、統合システムあるいはそれ以外のシステムと通信したとおりに、より効果的にタグを付けることが可能な、コンテンツおよびアイテムに加えられた変更を追跡する WebSphere Product Center 内の方法が必要になります。たとえば、WebSphere Product Center (ソース・システムとしての) 内でアイテムを削除する場合、同じアイテムを削除するようターゲット・システムに通知する、ターゲット・システムに送信されるメッセージをトリガーするだけでなく、アイテムが実際にターゲット・システムから削除されたかどうかを WebSphere Product Center が認識できるように、特定の通信の成功あるいは失敗をトラッキングできるようにしたい場合があるかもしれません。

再利用可能なコネクター

コネクター・リポジトリー

インプリメンテーションの進展と協力関係が発展するにつれて、さまざまなシステムへの再利用可能なコネクターのリポジトリーが徐々に構築されます。可能な場合にはいつでも、これらのコネクターを通して流れるアイテムなどの処理に関連した機能性を、特定のインプリメンテーションの観点から、ほとんどあるいは全く変更されずに再利用することができるように、これらのコネクターを再利用できるよう努力する必要があります。もちろん、これによって、インプリメンテーションの実行時の速度は全体として非常に速くなり、問題が見つかってやがて解決されるにつれて、コネクターとそれを使用するインプリメンテーション全体の信頼性や安定性は向上します。

コネクターをまだ定義していないシステムと統合する場合、特定のインプリメンテーションでの統合に使用でき、別のインプリメンテーションでシステムと統合する必要がある場合に、後で使用するためにコネクターのリポジトリーで保管することもできる、再利用可能なコネクターをすばやく作成できる統合のエキスパートが関与する必要があります。

コネクターの使用法

コネクターを使用して、システム間で渡される任意の情報の情報を処理する EAI レイヤーを通し、実行する必要のある変更を実行しなければなりません。言い換えると、EAI を介して渡される情報を処理するために WebSphere Product Center 内の再利用機能のいずれかを書き直す前に、必要な変換を実行する EAI プラットフォームの機能を利用すべきです。そうすれば、WebSphere Product Center の機能を書き直す必要はありません。


インプリメンテーション

インプリメンテーションのスケール調整

小さな統合

全体の統合の大きなタスクは、より小さい、より容易に管理できるタスクに分けるべきです。これは、たとえば、単一の完全な統合をより小さな統合に分けることによって行うことができます。つまり、それぞれのアイテム・タイプ (スペック) ごとの "個別の" 統合から、それぞれのコンテナー (カタログ) ごとの統合へ、属性のグループ (必要に応じて) ごとの統合に至るまで分けることができます。これらの "小さな統合" が完全に動作するという確信がある場合、それらを結合して単一の完全な統合を作成することができます。

機能の細分性

システム間の統合が発生するレベルに注意する必要があります。たとえば、変更をターゲット・システムに送信するときに、特定の日付以降のすべての変更を送信したい場合もあれば、最後に変更が送信されてから特定のカタログの変更のみ、特定のグループのアイテムで発生した変更のみ、あるいはすべてのアイテム間の特定の属性で発生した変更のみを送信できるようにしたい場合もあります。特定の要件はインプリメンテーションに依存していますが、それが適切に行われるようにインプリメンテーションの設計処理において必要な細分性を考慮することは重要です。

パフォーマンス・チューニング

一般的なパフォーマンスのコメント

パフォーマンスの問題を後回しにしてはなりません。統合の形式または他の局面を計画の後半で変更および修正することは容易ですが、パフォーマンスのボトルネックによって、重要な再設計や、時には技術サポートが必要になる可能性があります。開発のしかるべき過程において、パフォーマンスの測定フックをスクリプト内に置いてください。

パフォーマンスの測定

小さな統合のアプローチ (「インプリメンテーション」セクションで詳細に説明) を使用すると仮定した場合、パフォーマンスは、小さな統合の各タスクごとに必要な合計時間を測定することによって、統合の各ステップで測定する必要があります。パフォーマンスが低下することが考えられる領域は、適切な細分レベルで識別することができるため、パフォーマンスの微調整を行うためにより容易に的を絞ることができます。

パフォーマンスの微調整

パフォーマンスの問題領域が識別されたら、詳細な分析を行い、操作が遅くなる根本原因を判別する必要があります。詳細な分析は、WebSphere Product Center のミドルウェア・プロファイルのようなツールおよびジョブ詳細画面のパフォーマンス・タブを使用して行うことができます。さらに、その分析を適用して、スクリプトの特定の領域や SQL クエリーに焦点を当てることができます。また、適切なアクション (スクリプトの変更や書き直し、あるいはデータベース・クエリーを向上するためのエンジニアリングの関与) を実行することができます。

検証

安定性

小さな統合の利点

小さな統合 (「インプリメンテーション」セクションで詳細に説明) のインプリメントは、統合が作業中であることが示された全領域の詳細なリストを提供することによって、統合が正常に行われたという、より高いレベルの信頼性を提供します。小さな統合の可視性がないと、統合の作業に関する詳細情報の証拠を提供することが困難になるだけでなく、統合が全体として、識別、診断、およびデバッグが困難な問題に陥る可能性があります。小さな統合をインプリメントすることによって、統合の全体の安定性が向上します。

スケーラブルなテスト

小さな統合の利点

小さな統合 (「インプリメンテーション」セクションで詳細に説明) をインプリメントすることによって、統合のテストをより細かいレベルで行うことができ、生じるエラーまたは問題が多くの (おそらく無関係な) 複雑性によって不透明にならないようにします。こうして、上で説明したとおり、見つかった問題の診断、デバッグ、および解決の処理はすべて、このアプローチによって大幅に速度が向上します。

典型的な環境と完全な環境

統合テストは、最終環境 (同じスペック、検証ルール、値ルール、ビュー) と同じ構成を持つ典型的な環境で行うことができますが、可能な限り少ない典型的なエンティティー (ロケール、カタログ、カテゴリー・ツリー、アイテム、カテゴリー、組織、ユーザー、役割) を使用して行います。これにより、テストを実行したり、画面をロードする時間が削減され、一般的には、完全にデータが取り込まれた環境でのテストに対して、テストにかかる時間が短縮されます。すべてのテストおよびデバッグは、この環境で行わなければなりません。

典型的な環境でのみテストが完了し、すべてが作業中と表示された後、統合を完全な、そして完全にデータが取り込まれた環境で検証する必要があります。ただし、このステップは、典型的な環境においてエッジ・シナリオが誤って無視されないよう確認し、統合の製品レベルでのパフォーマンスをテストするために依然として実行されます。

スケーラブルな処理のテスト

スケジュール可能なジョブ (例、インポート、エクスポートなど) はまず、 非常に少ない代表的なアイテム (10 より少ない) のみを使用して実行する必要があります。 この数値は、実際にこれらのアイテムを処理中のスクリプト内で取られる信頼性のレベルに比例して増やす必要があります。 このアプローチは、全体の処理に実行の最初の数分間で明らかな障害を起こすことなく、 それを実行する人だけが最終的にどこかが間違っていることに気付くというように、 大量のジョブが問題となる時間にわたって実行される、ということがないようにします。

ジョブに関連したスクリプトの操作が十分に信頼を置けるものになってから、 完全なデータのセットに関連してジョブを実行する必要があります。完全な環境の推奨事項の場合と同様に、 このステップは、より小さなジョブにおいてエッジ・シナリオが誤って無視されないよう確認し、 ジョブの製品レベルでのパフォーマンスをテストするために実行すべきです。

可視性

レポート

小さな統合の利点

小さな統合 (「インプリメンテーション」セクションで詳細に説明) のインプリメントによって、統合がより小さく、また統合のインプリメントがより素早くなるため、より詳細なレベルのレポートが可能になります。統合全体のレベルでのインプリメンテーションの途上にあるレポートに比べて、このレポートの詳細なレベルにより、さらに具体的で数量的な統合の追跡が可能になります。

小さな統合はリストすることができ、グラフで詳細に説明されている完全な統合のより大きなピクチャーとの関連性、および統合の全体的な進展の正確なピクチャーは、小さな統合のタスクの進展に関するレポートから容易に描くことができます。

所有権

複数のチームで作業する場合でさえ、統合を通じて所有権を一人の人に割り当てます。この人のジョブは、単一スレッドが早く確立されるようにし、チームが本書のガイドラインに従って作業し、(a) 小さな統合、(b) スケーラブルな処理のテスト、および (c) 典型的な環境対完全な環境を通じて、インクリメンタルな構築 / テストのサイクルがさまざまなチーム間で同期化されるようにすることです。

文書

形式およびアプローチを明確に識別する

実行のための明確なパスを決定し、複数のチームが統合で作業する場合に使用される形式を明確に文書化します。最も一般的な例は、WebSphere Product Center チームが WebSphere Product Center からデータのエクスポートの作業をしており、顧客または SI チームが宛先システムにそのデータをアップロードしている場合です。共通の形式のスペックなしで作業を開始しないでください。またこの文書を毎日最新のものにしてください。これは、プロジェクト・マネージャーが実行する必要のある絶対要件です。

このアプローチは、典型的な環境の使用および小さな統合の実行とは矛盾していません。両方のチームは、増分的に構築およびテストして、着実な、目に見える進展を確実にしなければなりません。


WebSphere Product Center の統合に関する上位 10 のガイドライン

明確で一般的な用語を使用して、統合について説明する

すべてのインプリメンテーションは、セクション「統合の各次元」で識別される次元を使用する必要があります。

再利用性

スケーリングにとって重要なことは、「再利用性」セクションで説明されている再利用の原則を保ちながら、以前の統合から学習し、統合をパッケージすることにあります。

可視性

進展のレポート用に全体的なメトリックを確立し、最悪の場合でも数日ごとに明確な状況更新をプロジェクト・マネージャーに提供します。

小さな統合

大きな統合の複雑さを、その統合で意味のあるさまざまな次元 (カタログ、属性) に従って分割します。一度に 1 つの小さな統合に注目し、可視性のメトリックに直接結び付けます。

典型的な環境と完全な環境

デバッグおよびテストするのが容易な、典型的な環境を保持します。スクリプトおよびスペックの妥当性に関する確信が得られたときにのみ、完全な環境へ移動します。これを可視性メトリックに結び付けます。

スケーラブルな処理のテスト

すべてのジョブを小さなデータ・セットを使用してテストし、完全なデータ・セットにロールアウトする前に正確性をチェックします。これを可視性メトリックに結び付けます。

パフォーマンス

ロジックまたはフォーマットの正確性について心配せずに、開発サイクルで早めに幾つかのパフォーマンス・テストを実行し、その後定期的にテストを実行して、問題を識別します。

単一スレッドを早期に確立する

特に、複数のホップ、複数のプロトコル、または標準ではない方法を必要とする場合のある複雑な統合においては、統合の単一作業スレッドを早めに確立します。

仕様および文書の設計

実行のための明確なパスを定義して文書化し、特に複数のチームが統合で作業する場合に使用される形式を明確に文書化します。

単一の所有者

複数のチームで作業する場合でさえ、統合を通じて所有権を一人の人に割り当てます。


EAI プラットフォームの統合

アプローチ

汎用通信形式

可能な場合にはいつでも、汎用の通信形式を設計するか、以前のプロジェクトから再利用する必要があります。形式が一般的になればなるほど、すべてのシステムが互いに通信するために必要な形式の特別な再作業を行わずに、より多くのシステムを統合に含めることができます。もちろん、パフォーマンスにおいてトレードオフが生じる可能性があります。形式がより一般的になりますが、1 つのプロジェクトにとっての正しい形式が別のプロジェクトにとっては理想的な選択ではない場合があります。使用する特定の形式を判別する際に、依然として統合の各次元を考慮する必要があります。

コンテンツのマッピング

可能なかぎり、WebSphere Product Center コンテンツ・モデルと通信形式を通して示されるモデルとの間のマッピングは、動的に更新可能な方法で実行しなければなりません。 この場合も、統合の次元の調査に基づいて、特定のプロジェクトの必要性は、 (たとえば、処理の絶対最大スループットにより高い優先度が置かれているために、) これらのマッピングの作成を十分に動的に更新できないことを示している可能性があります。 これを行う 1 つの方法として、単一ノードの仕様をカテゴリー・ツリーに関連付けた状態で、 カテゴリー・ツリー (XML 構造などを表す) を使用することが挙げられます。 こうすると、属性の仕様ノード・パスで、カテゴリー・ツリーの特定のノード (WebSphereProduct Center コンテンツ・モデル内にマップされる) を示すことができます。 再帰的処理スクリプトを使用して、このカテゴリー・ファイルおよびその定義済みマッピングに基づいて、 XML ファイルへのアイテムのマッピングを処理し、ネストされた複数のオカレンスを容易に実行することができます。


追加の利点

情報の翻訳 / 変換

統合に関係したシステムは、統合における他のシステムの情報またはコンテンツの制限事項および要件を処理する必要はありません。 EAI プラットフォームを容易に利用して、このコンテンツの翻訳および変換を処理することができます。 たとえば、WebSphere Product Center が FLAG の値を "TRUE" あるいは "FALSE" として保管しても、 統合するシステムは、その値を "Y" あるいは "N" と保管することができます。 EAI プラットフォームを使用して、WebSphere Product Center が常に TRUE または FALSE を送信すると TRUE または FALSE と送信されると想定し、一方、統合システムは常に、Y または N と送信すると Y または N と送信されると想定するというようにこれらの翻訳を行うことができます。 これによって、全面的に、多くのシステムが統合に関連している場合でも、 これらの追加システムに照らし合わせて再コーディングの必要はなくなります。

クライアントに関する理解

クライアントは、すでに精通していると思われるプラットフォームを再利用できるため、 統合が既知の機能 (つまり、EAI プラットフォーム) を使用するという点で信頼性が増し加わります。 さらに、クライアント固有の通信形式がすでに存在し、WebSphere Product Center 統合にそれを再利用する場合、 クライアント側の開発者は、WebSphere Product Center がマッピングする通信形式を理解するための追加トレーニングをほとんど必要としません。

通信の柔軟性および信頼性

ほとんどの EAI プラットフォームには、さまざまなプロトコルに対して生じる通信を許可し、 ブローカリングによって通信を実現する、ネイティブの機能が含まれています。これにより WebSphere Product Center は、通信すべき必要な文書の生成だけに焦点を合わせることができ、この文書を各種のシステムに通信する異なる手段が潜在的に存在してそれをサポートするという点を考慮に入れる必要はありません。また、文書が各システムに受信されたかどうかを追跡するという点も考慮に入れる必要はありません。これらを考慮するのは、EAI レイヤーおよびプラットフォームとなり、WebSphere Product Center は単に、全体的な統合スレッドの観点からそうした点を認識していればすみます。