1

次のようなプロセスを構成したいと思います。

Method Call -> Dynamic Proxy Gateway -> Channel -> Service Activator -> Method Call
             ^---------- Transformer <- Channel <-             [return value]

事実上、Spring Integration が作成する隠しチャネルに何らかの方法でアクセスし、戻りメッセージのペイロードを別のメッセージ タイプに変換したいと考えています。

簡単な解決策は、最初はゲートウェイで default-reply-channel を構成することのように見えるかもしれません。問題は、OSGi を使用してバンドル間でチャネルを共有していることです。Service Activator は Bundle "B" によって提供され、着信要求に共有チャネルを提供します (データ プロバイダー サービスとして機能します)。バンドル「A」はデータを必要とするため、それを要求しますが、別の形式の結果が必要です。バンドル「B」がバンドル「A」によって指定されたデフォルト応答チャネルを使用できる場合、バンドル「A」はそれを共有する必要があることに注意してください。それはすべて公平で問題ありませんが、OSGi に循環依存関係があり、何も開始しません。

ここでの別の解決策は、Service Activator で出力チャネルを定義することのようですが、これには少し異なる問題があります。バンドル「B」から出力チャネルを共有すると仮定すると、循環依存の問題は軽減されましたが、誰かがバンドル「A」から何かを要求すると、出力チャネルに接続されているすべての人に応答が送信されます。これも望ましくありません.

[編集: ここで言いたいのは、「B」がそのサービス アクティベーターの入力チャネルと出力チャネルの両方を共有している場合、「B」の出力チャネルにバインドされている人は誰でも、「B」の入力に対する誰かの要求の結果を受け取るということです。チャネル -- 望ましい動作は、応答がリクエスタに向けられることです。

ここでのトランスフォーマーは、バンドル A のコンテキストでのみ意味があることに注意してください。バンドル B はサービスを提供します (すべての意図と目的のために、私が制御できないものです)。バンドル A のニーズに固有の変換は、バンドル A に存在する必要があります。]

したがって、私が本当に必要だと思うのは、動的プロキシ ゲートウェイへの応答でトランスフォーマーを構成できるようにすることですが、Spring Integration マニュアルでそのようなデバイスを見つけることができないので試してみてください。いつものように、助けていただければ幸いです。

--

編集2 :ここで他の2つの戦術を試みました:

  1. バンドル B の OSGi 共有チャネルを参照するサービス アクティベーターを使用する

    その結果、返された要素は GenericMessageType であり、これを変換できる可能性がありました。GenericMessageType は実際には、応答メッセージではなく、サービス アクティベーターが指し示す必要がある「send」メソッドのブール値の結果です。したがって、この方法は機能しません。

  2. ヘッダーエンリッチャーを使用して REPLY_CHANNEL を設定し、返信チャネルを値ではなく参照として渡します。

    この手法は機能しませんでした。ゲートウェイの default-reply-channel が設定されている場合 (および default-reply-channelを設定する必要がある場合)、REPLY_CHANNEL ヘッダー要素が無視されるようです。

4

2 に答える 2

1

理論的には、ここでの本当の答えはチェーンを使用することです。

バンドル A の構成は次のようになります。

<si:gateway id="gw" default-request-channel="xyz" />
<si:channel id="xyz" />
<si:chain input-channel="xyz" />
    <si:service-activator />
    <si:transformer />
</si:chain>

バンドル B の構成は変更されず、単一のチャネルのみが OSGi を介して共有され、バンドル A または任意の 3 次バンドルによるアクセスに使用されることに注意してください。

service-activator には次の 2 つのオプションがあります。

  1. OSGi による共有サービス
  2. 変換前に返されたデータ型のプロキシ ゲートウェイを呼び出すだけのカスタム サービス。

バンドル A のプロキシ ゲートウェイは、いくつかの入力チャネル「xyz」に注入し、最終的に暗黙のリターン チャネルには、必要に応じて変換されたコンテンツが含まれます。

このソリューションは、SingleShot によって提案されたソリューションとほぼ同じですが、ここでは OSGi を介した実際のサービスの共有を防ぎ、バンドルの境界を維持します。

于 2009-09-21T15:36:53.797 に答える
0

問題の説明に少し混乱しています。循環依存の側面とトランスフォーマーの側面は理解していますが、「Aに接続されているすべての人に返信が送信される」ことについてはよくわかりません。

B に 2 つのサービス アクティベーターが必要なように思えます。B にある既存のサービス アクティベーターはそのままで、ほとんどのクライアントがそれを使用します。もう 1 つは A に入り、A で定義されたチャネルのみを使用します。これにより、A から B への要求が、A の外部のコンポーネントによって応答が受信されるのを防ぐことができます。

これにより、変換の問題がより簡単になります。トランスフォーマーは、あるチャネルからメッセージを受け取り、それを変換して、別のチャネルに配置します。Aに1つ追加するだけで、うまくいくはずです。

したがって、A には、A のみが使用できるこれらのコンポーネントがあります。

  • ゲートウェイ
  • 入力チャンネル
  • B のサービス アクティベーター
  • 出力チャンネル
  • 変圧器
  • 変換された出力チャネル

B では、誰でも使用できるようになります。

  • 入力チャンネル
  • B のサービス アクティベーター
  • 出力チャンネル

A は B に依存しますが、B は A に依存しません。

それはうまくいきますか？

于 2009-09-14T22:55:44.010 に答える