TCP ゲートウェイ

受信 TCP ゲートウェイ TcpInboundGateway および送信 TCP ゲートウェイ TcpOutboundGateway は、それぞれサーバーおよびクライアント接続ファクトリを使用します。各接続は、一度に 1 つのリクエストまたはレスポンスを処理できます。

受信ゲートウェイは、受信ペイロードでメッセージを構築して requestChannel に送信した後、レスポンスを待機し、接続に書き込むことでレスポンスメッセージからペイロードを送信します。

受信ゲートウェイの場合、ip_connectionId ヘッダーは接続にメッセージを関連付けるために使用されるため、ip_connectionId ヘッダーを保持または追加する必要があります。ゲートウェイで発信されるメッセージには、ヘッダーが自動的に設定されます。返信が新しいメッセージとして作成される場合、ヘッダーを設定する必要があります。ヘッダー値は、受信メッセージから取得できます。

受信アダプターと同様に、受信ゲートウェイは通常、受信接続リクエストをリッスンする type="server" 接続ファクトリを使用します。場合によっては、受信ゲートウェイが外部サーバーに接続し、その接続で受信メッセージを待機して返信するように、逆に接続を確立することができます。

このトポロジは、受信ゲートウェイで client-mode="true" を使用することでサポートされます。この場合、接続ファクトリの型は client でなければならず、single-use を false に設定する必要があります。

2 つの追加の属性がこのメカニズムをサポートします。retry-interval は、フレームワークが接続失敗後に再接続を試行する頻度を (ミリ秒単位で) 指定します。scheduler は TaskScheduler を提供して、接続の試行をスケジュールし、接続がまだアクティブであることをテストします。

ゲートウェイが開始されている場合は、<control-bus/> コマンド @adapter_id.retryConnection() を送信してゲートウェイに接続を確立させ、@adapter_id.isClientModeConnected() で現在の状態を調べることができます。

送信ゲートウェイは、接続を介してメッセージを送信した後、レスポンスを待機し、レスポンスメッセージを構築して、レスポンスチャネルに配置します。接続を介した通信はシングルスレッドです。一度に処理できるメッセージは 1 つだけです。現在のレスポンスを受信する前に別のスレッドがメッセージを送信しようとすると、以前のリクエストが完了する（またはタイムアウトする）までブロックされます。ただし、クライアント接続ファクトリが使い捨て接続用に構成されている場合、新しいリクエストはそれぞれ独自の接続を取得し、すぐに処理されます。次の例は、受信 TCP ゲートウェイを構成します。

<int-ip:tcp-inbound-gateway id="inGateway"
    request-channel="tcpChannel"
    reply-channel="replyChannel"
    connection-factory="cfServer"
    reply-timeout="10000"/>

デフォルトのシリアライザーまたはデシリアライザーで構成された接続ファクトリが使用される場合、メッセージは \r\n で区切られたデータであり、telnet などの単純なクライアントがゲートウェイを使用できます。

次の例は、送信 TCP ゲートウェイを示しています。

<int-ip:tcp-outbound-gateway id="outGateway"
    request-channel="tcpChannel"
    reply-channel="replyChannel"
    connection-factory="cfClient"
    request-timeout="10000"
    remote-timeout="10000"/> <!-- or e.g. remote-timeout-expression="headers['timeout']" -->

client-mode は現在、送信ゲートウェイでは使用できません。

バージョン 5.2 以降、発信ゲートウェイはプロパティ closeStreamAfterSend で構成できます。接続ファクトリが single-use （各リクエスト / 応答の新しい接続）用に構成されている場合、ゲートウェイは出力ストリームを閉じます。これは、サーバーに EOF を通知します。これは、サーバーがストリーム内の区切り文字ではなく EOF を使用してメッセージの終わりを判別する場合に役立ちますが、応答を受信するために接続を開いたままにします。

通常、呼び出しスレッドはゲートウェイでブロックされ、応答（またはタイムアウト）を待ちます。バージョン 5.3 以降、ゲートウェイで async プロパティを設定でき、送信スレッドが解放されて他の作業を行うことができます。返信（またはエラー）は受信スレッドで送信されます。これは、TcpNetClientConnectionFactory を使用する場合にのみ適用されます。NIO を使用する場合は無視されます。これは、応答の受信後に発生するソケットエラーが、応答の前にゲートウェイに渡される可能性があるためです。

共有接続（singleUse=false）を使用している場合、新しいリクエストは、別のリクエストが処理されている間、現在の応答が受信されるまでブロックされます。長期間有効な接続のプールでの同時リクエストをサポートする場合は、CachingClientConnectionFactory の使用を検討してください。

バージョン 5.4 以降、受信は unsolicitedMessageChannel で構成できます。未承諾の受信メッセージがこのチャネルに送信され、返信が遅れます（クライアントがタイムアウトした場合）。サーバー側でこれをサポートするために、複数の TcpSender を接続ファクトリに登録できるようになりました。ゲートウェイとチャネルアダプターは自動的に登録されます。サーバーから一方的なメッセージを送信する場合は、送信するメッセージに適切な IpHeaders.CONNECTION_ID を追加する必要があります。

アノテーションベースの構成および TCP コンポーネントに JavaDSL を使用するも参照してください。