1

次の構成を使用して実装された簡単なリクエスト応答テストがあります。

<int:gateway id="myGateway"
    service-interface="TestGateway" 
    default-request-channel="sendingChannel"
    default-reply-channel="replyChannel"
    default-reply-timeout="2000"
    />

<int:channel id="sendingChannel" />
<int:channel id="replyChannel" />

<int-jms:outbound-gateway id="myJmsGateway"
    connection-factory="jmsConnectionFactory"
    request-channel="sendingChannel"
    request-destination-name="outQueue"
    reply-channel="replyChannel"
    reply-destination-name="outQueueReply"
    receive-timeout="60000"
    />

およびインターフェイス:

public interface TestGateway {
    @Gateway
    public String requestReply(@Header("myHeaderKey") String headerValue, String data);
}

上記の構成は「機能」しますが、次の予約があります。

  1. 構成は冗長に感じます。追加のゲートウェイと 2 つの追加チャネルが必要です。どちらのゲートウェイも応答タイムアウトを実装しています (ただし、int:gatewayに接続されている場合はタイムアウトは発生しませんint-jms:outbound-gateway)。

  2. ゲートウェイ メソッドのセマンティクスは、要求/応答を実装しているものによって異なります。タイムアウトにint-jms:outbound-gatewayなると、 は例外をスローし、それが のユーザーに伝播しますTestGateway。構成を置き換えるように変更するとint-jms:outbound-gateway、int:gatewaynull が返されます。

これを考えると、クライアント コードは null と例外の両方を同じ方法で処理する必要があります。

ゲートウェイを配線するためのより良い方法はありますか? 1 つのオプションは、追加のスレッド プールを犠牲にして、問題 2 を解決するint:channel'sをに変更することです。PollableChannel's

4

1 に答える 1

2
  1. 返信チャネルを構成する必要はありません。デフォルトでは、jms ゲートウェイ (応答チャネルなし) はメッセージを受信ゲートウェイに自動的に返します。
  2. 直接チャネルを使用する場合、メッセージング ゲートウェイのタイムアウトは、スレッドがフローから返された応答を受信しようとしたときにのみ開始されます。

error-channel受信ゲートウェイに を追加することで、異なるセマンティクス (null Vs 例外) を回避できます。

myGatewayクライアントをメッセージング システムから分離することを理解することが重要です。インターフェイスのみにコーディングします。もちろん、JMS ゲートウェイを直接注入することもできますが、コードに依存関係を追加してしまいます。メッセージング ゲートウェイを使用すると、クライアント コードを変更せずにテクノロジを変更できます。のテスト実装を提供することで、コードを単体テストすることもできますTestGateway。これは Spring Integration の強力な機能です。

于 2013-09-18T16:13:25.687 に答える