Inbound-Transformator zum Spring Integration Proxy-Gateway

Question

Ich möchte einen Prozess konfigurieren, wie etwas aussieht:

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

Effektiv würde ich irgendwie mag den verborgenen Kanal zugreifen Frühling Integration schafft und verwandeln die Rückmeldung Nutzlast in einen anderen Nachrichtentyp.

Eine einfache Lösung zunächst auf dem Gateway zu der Konfiguration einen Standard-Antwort-Kanales erscheinen mag, ist das Problem, dass ich den Kanal zwischen Bündel mit OSGi bin zu teilen. Das Service Activator wird durch Bundle „B“ vorgesehen sind, und bietet einen gemeinsam genutzten Kanal für eingehende Anforderungen (es wirkt als Datenprovider-Service). Bundle „A“ benötigt einige Daten, so dass er es verlangt, muss aber das Ergebnis in einem anderen Format. Beachten Sie, dass, wenn Bundle „B“ waren in der Lage sein, die default-Antwort-Kanal durch Bundle spezifiziert die Verwendung von „A“ dann Bundle „A“ es teilen müssen. Das ist alles fair und gut, aber dann habe ich eine zirkuläre Abhängigkeit in OSGi, und nichts würde beginnen.

Es scheint, wie hier eine andere Lösung, die einen Ausgabe-Kanal auf dem Service Activator wäre zu definieren, aber diese leiden unter einem etwas anderen Problem. Unter der Annahme, ich den Ausgabe-Kanal von Bundle teilen „B“ Ich habe das Kreisabhängigkeitsproblem entschärft habe, aber jetzt jederzeit jemand fordert etwas von Bundle „A“ die Antwort geht an alle an den Ausgangskanal angebracht - auch dies ist nicht wünschenswert, .

[ Bearbeiten : Was ich hier meine ist, dass, wenn „B“ Aktien sowohl einen Eingang und einen Ausgangskanal für seinen Dienst Aktivator dann jemand gebunden „B“ 's Ausgangskanal wird das Ergebnis erhalten von jeder Anforderung auf „B“ 's-Eingangskanal - und dem gewünschten Verhalten ist, dass die Antworten an den Anforderer gerichtet sind

.

sollte ich beachten Sie, dass der Transformator hier sinnvoll ist nur im Rahmen von Bundle A. Bundle B bietet einen Service (für alle Absichten und Zwecke, die ich keine Kontrolle haben über). Die Transformation, speziell auf die Bedürfnisse von Bundle A sollte in Bundle A befindet.]

Also, was ich denke, ich wirklich brauchen, ist ein Transformator auf Antworten auf einen dynamischen Proxy-Gateway in der Lage sein zu konfigurieren, sondern versuchen, wie ich könnte ich nicht ein solches Gerät im Frühjahr Integration Handbuch finden. Wie immer würde Hilfe sehr geschätzt.

-

Edit 2 : Ich habe versucht, zwei andere Taktik hier:

1. einen Service-Aktivator verwenden, das den OSGi-Shared-Channel von Bündel B bezeichnet

   Das Ergebnis war, dass das zurückgegebene Element ein GenericMessageType war - was es möglich sein könnte, zu transformieren. Die GenericMessageType ist wirklich das boolean Ergebnis des Verfahrens „Senden“, das der Service-Aktivator zeigen muss, nicht die Antwortnachricht. So dass diese Methode funktioniert nicht Arbeit.

2. einen Kopf enricher Verwenden Sie auf REPLY_CHANNEL und den Antwortkanal als Referenz übergibt, anstatt ein Wert.

   Diese Technik hat nicht Arbeit, das REPLY_CHANNEL Kopfelement erscheint ignoriert werden, wenn der default-Antwort-Kanal des Gateways eingestellt ist (und der Standard-Antwort-Kanal muß gesetzt werden).

Answer 1

die wirkliche Antwort hier Theoretisch ist eine Kette zu verwenden.

Die Konfiguration für Bundle A wird so etwas wie

aussehen

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

Hinweis für Bündel B die Konfiguration unverändert ist, und nur ein einziger Kanal wird für den Zugriff durch Bündel einer oder jede tertiären Bündel durch OSGi geteilt.

Zwei Optionen für den Service-Aktivator zur Verfügung:

1. Shared Service durch OSGi
2. Benutzerdefinierte Service, der einfach einen Proxy-Gateway für die Pre-Transformation ruft zurückzuDatenTyp.

Der Proxy-Gateway in Bundle A wird injiziert in eine Eingangskanal „xyz“ und letztlich der implizite Rückkanal wird enthielt den transformierten Gehalt wie gewünscht.

Diese Lösung ist fast das gleiche wie die von Single vorgeschlagen, aber hier haben wir die gemeinsame Nutzung eines echten Service durch OSGi, Aufrechterhaltung Bündelgrenzen zu verhindern.

Answer 2

Ich bin ein wenig verwirrt von der Problembeschreibung. Ich verstehe den zirkulären Abhängigkeit Aspekt und den Transformator Aspekt, aber ich bin nicht so sicher „die Antwort auf jedem geht an A gebunden“.

Es klingt ein bisschen wie Sie zwei Service-Aktivatoren für B. haben möchten vielleicht würde Ihre bestehende in B bleiben, und die meisten Kunden würden es verwenden. Der andere würde in A gehen, und nur die Kanäle in A definiert Dies würde verhindern, dass Anfragen von A nach B aus, was zu Antworten, die durch Komponenten außerhalb A.

empfangen werden, verwenden würde

Dies sollte das Problem der Transformation erleichtern. Transformatoren nehmen eine Nachricht von einem Kanal, transformieren, und es auf einem anderen Ort. Fügen Sie einfach ein in A und Sie sollten gut sein.

So in A würden Sie diese Komponenten haben, nur verwendbar durch A:

• ein Gateway
• ein Eingangskanal
• a-Service-Aktivator für B
• ein Ausgangskanal
• ein Transformator
• ein transformierte Ausgangskanal

In B würden haben, nutzbar von jedem:

• ein Eingangskanal
• a-Service-Aktivator für B
• ein Ausgangskanal

A hängt von B, aber B hängt nicht von A.

Wird das funktionieren?