PIMO フレームワーク

TCP/IP 接続を介して着信するメッセージ構造をデータ・ハンドラーに送信して WebSphere Business Integration Server Express ビジネス・オブジェクトに変換するには、その前にメッセージ構造に対して一定の規模の前処理が必要な場合があります。

例えば、HL7 という医療業界のデータ標準について考えます。ネットワーク送信エラーの検出と修正の詳細は、最新のネットワーク・プロトコルの大半では下位レベルが処理するため、主要な標準には、これらを網羅する仕様が盛り込まれていません。ただし、HL7 データ・フローの一部になる場合がある多くのミニ・コンピューター・システムやメインフレーム・コンピューター・システムは、下位層の機能が十分には提供されない通信環境で動作します。これらの場合に、HL7 は、Hybrid Low Layer Protocol や Minimal Low Layer Protocol など、異なる環境に適合するいくつかの下位層プロトコルを代替として提供します。これらのプロトコルを使用して送信されるメッセージについては、データの本体を抽出する前に前処理して、このプロトコルに関連する情報を削除しておく必要があります。

TCP/IP コネクターの PIMO インフラストラクチャーは、まさにこの種の前処理を実行する目的で設計されています。Production Instruction Meta Object フレームワークは、コネクター・レベルでのビジネス・ロジック処理に効果を発揮するための、柔軟性の高い汎用の抽象概念です。PIMO インフラストラクチャーは、幅広い動作が可能であり、他のアダプター内では別の形で使用されます。TCP/IP コネクターの内部では、これらの前処理問題および後処理問題の対処専用にカスタマイズされています。

PIMO フレームワークは、専用に設計された 1 組のメタオブジェクトを使用して、その作業を実行します。アダプターの PIMO 階層の最上位は、BIA_MO_Tcpip_MapSubscriptions オブジェクトです。BIA_MO_Tcpip_MapSubscriptions の図に、このオブジェクトを Business Object Designer Express で表示した場合の外観を示します。このオブジェクトは、データの経路となるインバウンド (イベント前処理) パスおよびアウトバウンド (サービス呼び出し要求後処理) パスの両方を指定します。このオブジェクトには、BIA_MO_Tcpip_MapSubscriptions_In および同等の Out オブジェクトの 2 つのオブジェクトが格納されており、それぞれのオブジェクトには、該当する PIMO マップ・オブジェクトへの参照が格納されています。前述の HL7 オブジェクトの場合、該当する In PIMO マップ・オブジェクトは、BIA_Map_InputMessage_to_LLPMessageList になります。BIA_Map_InputMessage_to_LLPMessageListを参照すると、このオブジェクトを Business Object Designer Express で表示した場合の外観が分かります。

この PIMO マップ・オブジェクトは、コア PIMO オブジェクトとして機能します。PIMO オブジェクトは、Port、Declaration、および Action の 3 つの基本属性で構成されます。

各 Port は、さらに IPort と OPort の 2 つの属性で構成されます。これらは、送信元オブジェクト (例えば、イベント処理の内部ラッパー・オブジェクトである BIA_InputMessage オブジェクト) と宛先オブジェクト (BIA_LLPMessage List オブジェクト) の予想タイプを示しています。BIA_MO_Tcpip_MapSubscriptions ページの例では、チェーニングされた (連動する) 2 つの入力マップを示します。最初のマップは複数のメッセージを単一メッセージに分離し、2 番目のマップは実際の HL7 メッセージから LLP 情報を除去します。この処理を複数のステップに分割すると、チェーニング・マップは、より複雑なタイプの処理を生成できます。チェーニングされたマップを使用する場合は、ステップ 1 の OPort タイプは、ステップ 2 の IPort タイプと完全に一致するなどの条件が必須です。

Declaration 属性はオプションです。この属性には、処理中に使用する一時変数の名前が書き込まれています。この例では、Declaration オブジェクトに「contentText」などの名前が格納されています。

最後に、PIMO マップには Action 属性が格納されます。各 Action 属性は、定義済みの 1 つ以上の Action で構成されます。定義済みの Action ごとのアプリケーション固有の情報 (ASI) は、必要な実際のデータ変換を実行する目的で設計されたネイティブ Java クラスであるメッセージ・ハンドラーを呼び出すために PIMO が必要とする情報を提供します。BIA_Map_InputMessage_to_LLPMessageList ページの ASI の例から、必要な情報を示します。その内容は次のとおりです。

type=nativeStatic; class=com.im.adapters.tcpip.messagehandlers.LLPMessagingProtocoHandler; method=parseInputMessageToLLPMessages; target=contentText;IPort;Oport

ASI には、次の情報が記述されています。

type =
このリリースでは、この値は必ず nativeStatic になります。現在の PIMO 構造体がサポートしているのは、共通の静的メソッドのみです。
class =
この値は、メソッドを格納している Java クラスの完全修飾名を表します。この例では、 com.ibm.adapters.tcpip.messagehandlers.LLPMessagingProtocolHandler です。
method =
この値は、呼び出しの対象となるメソッドを表します。この例では、parseInputMessageToLLPMessages です。
target =
この値は、戻されたデータの格納場所を表します。この例では、データの格納先は Declaration 属性に作成された変数 contentText です。
var1, var2 . . . varx
メソッドに渡されるパラメーターのオープン・リストです。このリストにおける変数の順序と数は、メソッドが予想するパラメーターの順序と数に完全に一致する必要があります。この例では、var1 と var2 は、それぞれ Port 属性の IPort ビジネス・オブジェクトおよび OPort ビジネス・オブジェクトになります。

この設定の中核をなすメソッドである parseInputMessageToLLPMessages には、LLP 固有のラッパー・データを抽出し、LLPMessage の個々の部分 (ヘッダー、メッセージ自体、およびトレーラー) を格納するリストを戻す方法が組み込まれています。これにより、メッセージを (BIA_ContentBO として) データ・ハンドラーに渡すことができます。これらの一連の HL7 メッセージ・ハンドラーは、TCP/IP のインストール環境に組み込まれていますが、その他も必要に応じて開発できます。

繰り返しますが、サービス呼び出し要求処理は、同じ段階を逆方向にたどります。PIMO フレームワークを使用して、メッセージをそのプロトコル固有データでラップし、その後、リモート・ホストに転送します。

Copyright IBM Corp. 2004, 2005