TCPIP Handshake サンプルは、TCPIPServerInput、TCPIPServerOutput、TCPIPServerReceive ノードを使用します。
これらのノードがどのように機能し、構成されるかに関する概要は、IBM Integration Bus 資料の TCP/IP の概要を参照してください。
既存の TCP/IP サービスを WebSphere MQ サービスに置換済みである一方で、一部のクライアントがこの新規サービスにまだマイグレーションされていない場合、このサンプル・フローを使用することができます。
既存のサービスは、要求/応答サービスをインプリメントする TCP/IP サーバーです。 データ交換の要求と応答の両方のサイドで、3 方向ハンドシェークが行われます。 3 方向ハンドシェークは、処理に時間がかかり過ぎている要求をクライアントがキャンセルするためのメカニズムとして機能します。ハンドシェークはアプリケーション層内にインプリメントされているので、TCP/IP 接続を切断しなくてもキャンセルを実行することができます。
以下のステップは、ハンドシェークの方法を示しています。
要求:次のように、プロセス中に時間遅延が起きる可能性があります。
クライアントは、プロセス中の以下の 2 つの時点で要求をキャンセルすることができます。
6 つすべてのメッセージの物理形式は、所有権付きの形式で定義されます。
新規サービスは、各応答とそれに対応する要求を相互に関連付けるための MQMD の「相関 ID」フィールドの使用に関する標準の WebSphere MQ 規則を使用する、WebSphere MQ 要求/応答サービスです。要求メッセージと応答メッセージは、両方とも XML 形式です。
メッセージ・フローは、交換されるデータのシーケンスと物理形式という点で、新規の WebSphere MQ サービスをオリジナルの TCP/IP サービスに似せるための素材とみなすことができます。
TCPIPMQVeneer メッセージ・フローは、以下の 3 つのサブフローで構成されます。
このサブフローは、TCP/IP クライアントから要求を受信するための 3 ウェイ・ハンドシェークを実装します。
このサブフローは、TCP/IP 接続から要求を受け取り、同じ接続上で確認応答を返送し、確認を待機します。
この要求は、TCPIPServerInput ノードのメッセージ・ツリーにデータを取り込むのに使用されます。 確認応答と確認は、両方ともローカル環境ツリー内で構成されます。 要求メッセージは、サブフローによって変更されることはありません。
MakeAcknowledgement ノードと CheckConfirmation ノードで使用される MakeRequestAck クラスと CheckRequestConf クラスを調べて、確認応答の構成と確認の使用のためにローカル環境がどのように使用されるかを確認します。 これらのクラスは、新規の MbMessages を一切作成しません。 変更はすべて、入力ローカル環境に対して加えられ、それがさらに伝搬されることになります。 入力メッセージはまったく変更されません。それは、次のような理由で重要です。
TCPIPServerOutput ノードおよび TCPIPServerReceive ノードの「ID の場所」プロパティーを $LocalEnvironment/TCPIP/Input/ConnectionDetails/Id に設定して、要求の受信場所と同じ接続上で、必ず確認応答が返送され、確認が待機されるようにします。
TCPIPServerReceive ノードでは、「データ・レコード待機のタイムアウト (秒)」プロパティーは 60 秒に設定されていて、ノードの Timeout ターミナルはワイヤリングされていません。 したがって、クライアントが、要求を送信した後に送信される確認応答から 60 秒以内に確認を送信できなかった場合、TCPIPServerReceive ノードから例外が生成されます。 CheckConfirmation ノードの Java クラス CheckRequestConf では、見込みどおりの値が確認メッセージに入っていないと、否定の確認とみなされて、その要求は、Throw ノードにつながる Alternate ターミナルに伝搬されます。 したがって、クライアントが否定確認を送信すると、クライアントが 60 秒以内に確認を送信しなかった場合と同じ結果を生じます。 つまり、例外が生成されて、要求がキャンセルされます。
このサブフローは、XML 形式へのデータの変換も含め、WebSphere MQ とのハンドシェークをインプリメントします。
このサブフローは以下を行います。
sendReply サブフロー内の TCPIP ノードが、receiveRequest サブフローと同じ接続を必ず使用できるようにするためには、ローカル環境を保存またはコピーすることが不可欠です。
他の 2 つのサブフローを変更しなくても、別のタイプのサービスを呼び出すために invokeMQService サブフローを置き換えることができます。
invokeMQService サブフローを変更または置き換える方法の例を以下に示します。
MQGet ノードを使用する代わりに MQInput ノードを使用して、WebSphere MQ サービスを非同期で呼び出せるようにすることができます。 ただし、このサブフローの出力は、ローカル環境内の正しい値を持っている必要があります。それは、sendReply サブフローが、receiveRequest サブフローと同じ接続を使用できるようにするためです。 したがって、接続 ID とペアになる WebSphere MQ メッセージ ID のマップを保管する必要があります。 HTTP ノード・サンプルは、そのマップをメッセージとして別の WebSphere MQ キューに保管する方法を示しています。 マップを保管するその他のオプションとして、次のものがあります。
TCP/IP サーバーを Web サービスに置き換える場合、invokeMQService サブフローではなく invokeWebService サブフローを使用する必要があります。 invokeWebService サブフローを構成するには、SOAPRequest ノードを使用します。 Web サービス・コンシューマー・フローの構成方法の詳細は、SOAP ノード・サンプルを参照してください。
このサブフローは、TCP/IP クライアントへの応答の返送のための 3 ウェイ・ハンドシェークを実装します。
このサブフローは、応答を送信し、クライアントからの確認応答を受け取るまで待機し、その後クライアントに確認を返送すると、ハンドシェークが完了します。
このサブフローは、次のような点で receiveRequest サブフローに似通っています。