it-swarm.com.de

SOAP Web-Service-Callback-Architektur?

Ich bin ziemlich neu in Webservices, JAX-WS usw., also vielleicht keine Frage ...

Daher möchte ich einen Webdienst implementieren, um die Kommunikation zwischen zwei Systemen zu ermöglichen. Das "Client" -System ist an Ereignissen interessiert, die auf dem "Server" -System generiert werden. Das "Client-System" ist jedoch selbst ein Server für eine andere App. Der Server ist Java (WAR in Tomcat). Der Client ist .Net.

Es sollte nur ein Client-System geben, aber mehrere Client-Prozesse im Client-System, die jeweils an unterschiedlichen Ereigniskategorien interessiert sind.

Ich werde die Server-Seite und einen Test-Client implementieren. Jemand anderes wird den .Net-Code implementieren.

Die Laufsequenz sollte ungefähr so ​​aussehen:

  1. Server läuft ...
  2. Der Client initiiert eine Konversation, "registriert" sich beim Server und fordert einige anfängliche Daten an.
  3. Der Server führt eine Liste der Endpunkte der registrierten Clients
  4. Auf dem Server befindet sich ein Listener, der benachrichtigt wird, wenn bestimmte Ereignisse eintreten. Es geht dann die Liste der registrierten Kunden durch und leitet das Ereignis an jeden von ihnen weiter
  5. Irgendwann kann der Client die Registrierung aufheben und den Server nicht mehr darüber informieren, dass er keine Ereignisse mehr empfangen möchte.

Klingt es nach etwas, das vernünftigerweise machbar ist?

Und gibt es einen integrierten Standardmechanismus mit SOAP (JAX-WS auf dem Server, was auch immer mit .Net auf dem Client verfügbar ist), mit dem der Server einen Callback-Endpunkt vom Client abrufen kann ?

Ich habe zum Beispiel etwas sehr ähnliches mit RMI gemacht. In diesem Fall kann der Client nur eine entfernte Referenz an sich selbst senden, auf die der Server später nur noch verweisen kann.

Gibt es eine Standardbibliothek zum Speichern von Endpunktreferenzen, zum Durchführen von (kollektiven) Rückrufen und möglicherweise zum Aktualisieren der Liste, um die Clients zu entfernen, die nicht auf so einen "Ping" -Aufruf reagieren?

Hinweis zur Verdeutlichung: Ich benötige mehr als nur eine asynchrone Methode mit Rückruf: Eine Nachricht vom Client generiert viele Rückrufnachrichten von Server zu Client.

22
Pierre Henry

Sie möchten eine Benachrichtigungsfunktion implementieren, um beliebige anonyme Clients zu informieren.

Ich schlage vor, dass Sie zuerst überlegen, wie Sie die Informationen mit SOAP -Nachrichten weitergeben. Dann können Sie überlegen, wie Sie dies mit Java-JAX-WS oder zusätzlichen Nicht-Standard-Bibliotheken erreichen können. Der Punkt ist, dass es möglicherweise erhebliche Einschränkungen oder Annahmen gibt, um SOAP Nachrichten zu übertragen. Z.B. Firewalls blockieren möglicherweise Ihre HTTP-Nachrichten. Clients können "nur Clients" sein, die nicht in der Lage sind, in einer Serverrolle SOAP Benachrichtigungsanforderungen zu erhalten 

Hinweis: In JAX-WS 2.0 ist ein asynchroner Rückrufmechanismus definiert, bei dem der Dienst die Endpunktreferenz des Clients abruft. Dies ist die gleiche Funktionalität, die von der proprietären WebLogic/Fusion-Lösung bereitgestellt wird, die von Deepak Bala beschrieben wird. Websphere hat eine ähnliche proprietäre async-Lösung. Keines davon erfüllt Ihre Anforderungen, da nur eine einzige Antwort pro Anfrage zulässig ist.

SOAP-Optionen:

  1. Proprietäre SOAP Nachrichten - die "100% Do-It-Yourself-Option" 

    Sie entwerfen vollständige SOAP Payload-Schemas und ein Muster für den Nachrichtenaustausch. 

    Sie können die Benachrichtigung vom Server an den Client senden, wenn Sie die Endpunktadresse des Clients SOAP kennen. Der Client kann seine SOAP Endpunktadresse innerhalb der ursprünglichen SOAP Anforderungsnutzlast übertragen. Einige Zeit später kann der Server eine SOAP -Anforderung an den Client senden. 

    Probleme/Annahmen: (1) Sie benötigen einen SOAP/HTTP-Kommunikationspfad für Anforderungen von Server zu Client. Wenn Firewalls vorhanden sind, kann dies nicht garantiert werden. (2) Der Client muss über Ihr Benachrichtigungsschema informiert sein. Der Client muss als Service-Endpunkt fungieren, um die Benachrichtigungsanforderung SOAP zu erhalten. Dies sind zwei große Annahmen WENN Sie versuchen, beliebige anonyme Clients zu unterstützen - das ist nichts, was SOAP "nur unterstützt", dass beide Enden dies alles im Detail entwerfen müssen. Um dies auf eine typsichere Art und Weise zu tun, sollte der Client tatsächlich seine eigene WSDL-Schnittstelle für den Service angeben, damit Sie sie aufrufen können. (3) Wie bereits angedeutet, sind viele Clients "nur Clients" - sie verfügen möglicherweise nicht über einen HTTP-Server, um SOAP-Anforderungen anzunehmen.

    Damit proprietäre Push-Benachrichtigungen funktionieren, müssen beide Seiten Server verwenden, und beide müssen ihre SOA -Interfaces veröffentlichen.

    Alternativ können Sie die Benachrichtigung an den Client ziehen. Der Client kann eine Benachrichtigungsanforderung an den Server verwenden, die entweder blockiert oder abfragt. Der Server kann mit der Benachrichtigung oder mit nichts oder einem Fehler antworten.

    Probleme/Annahmen: (1) HTTP-Server (d. H. Der SOAP-Server) unterstützen in der Regel keine blockierenden Anforderungen. Dies bedeutet, dass Sie abfragen müssen. (2) Der Client muss über Ihr Benachrichtigungsschema informiert sein. Der Client muss als Service-Endpunkt fungieren, um die Benachrichtigungsanforderung SOAP zu erhalten. Das sind zwei sehr große Annahmen für einen beliebigen anonymen Client - das ist nicht etwas, das SOAP "nur unterstützt", dass beide Enden alles im Detail entwerfen müssen. Um dies auf eine typsichere Art und Weise zu tun, sollte der Client tatsächlich seine eigene WSDL-Schnittstelle für den Service angeben, damit Sie sie aufrufen können.

  2. Wie oben, jedoch WS-Adressierungsdaten in SOAP -Header einschließen, um beide Seiten über die Endpunktadresse des anderen zu informieren.

    Grundsätzlich die gleichen Probleme/Annahmen wie bei der ersten Option. WS-Adressierungsadressen helfen Ihnen, SOAP -Nachrichten intelligent an die richtige URL-Adresse weiterzuleiten, jedoch nicht mehr.

  3. WS-Benachrichtigung verwenden

    Diese Spezifikation wurde für Ihr Szenario entwickelt.
    Der WS-BaseNotification-Substandard würde Ihre Anforderungen erfüllen. Sie enthält WSDL-Portdefinitionen für Benachrichtigungsproduzenten und -verbraucher. Es bietet eine WS-Standards-konforme Lösung für das Abonnement eines Verbrauchers an einen Hersteller und eine Benachrichtigung von Produzenten an den Verbraucher.

    Probleme/Einschränkungen: (1) Es definiert NICHT das Format der Benachrichtigungsnutzdaten. Die Benachrichtigungs-Payload ist anwendungsdomänenspezifisch (proprietärer Entwurf). Der Standard definiert keine "Standard" - oder "Integrierten" Benachrichtigungssituationen oder Meldungen. (2) Es hat die gleichen Probleme mit HTTP-Benachrichtigungen, die durch Firewalls geleitet werden, wie oben erwähnt. (3) WS-Notification ist kein unterstützter Standard für Java EE/JAX-WS (es gibt jedoch viele App-Server.) Open Source und Commercial, die es als Erweiterung unterstützen).

  4. Verwenden Sie eine Lösung für die Nachrichtenwarteschlange (z. B. JMS) mit in HTTP Gekapseltem Datenverkehr. Dies erfordert einen proprietären Entwurf von Nutzdaten, die zwischen Client und Server übertragen werden, und Back-Forming-Verträge zwischen den beiden Seiten. Ein Vorteil besteht darin, dass der Client ein reiner Client sein kann, wobei ein Nachrichten-Listener in einem Thread aufgerufen wird, wenn eine Nachricht empfangen wird.

    Probleme/Einschränkungen: (1) Es hat die gleichen Probleme mit HTTP-Benachrichtigungen, die durch Firewalls geleitet werden, wie oben erwähnt. (2) Ist eine Do-it-Yourself-Implementierung. (3) Verwendet mehr Technologie als Sie derzeit verwenden.

Endresultat:
Sie benötigen mindestens einen Teil Ihrer Lösung, um ein proprietäres Design zu sein - die SOAP/WS-Standards erfüllen nicht Ihre vollständigen Anforderungen. Theoretisch könnte dieses proprietäre Design ein Produkt einsetzen, um einen Großteil der Arbeit zu leisten, ABER das Benachrichtigungsschema-Design müsste von Ihnen erstellt und integriert werden. 

Wenn Sie Benachrichtigungen per Push versenden möchten, benötigen Sie some eine Art Vertrag, in dem Benachrichtigungen an den Client weitergeleitet werden. Der Client muss als SOA - Server fungieren, und Sie benötigen die für Ihren Browser geöffneten Firewalls der Verkehr. Die meisten Unternehmen lassen keine HTTP-Anforderungen zu, die einen Server verlassen und an einen Client weiterleiten. Normalerweise benötigen Sie einen extrem guten Grund, um Firewall-Ports zu öffnen.

Wenn Sie möchten, dass Clients Benachrichtigungen abfragen, benötigen Sie lediglich eine grundlegende WSDL-Schnittstelle auf der Serverseite, die häufig von Clients aufgerufen werden kann. 

Zukünftige Option: HTML5-Web-Sockets
Wenn es sich bei Ihrem Client um eine HTML5-App handelt, können Web-Sockets-fähige Server den Datenverkehr an den Browser senden - und es besteht die Möglichkeit, dass Unternehmen Firewalls öffnen. SOAP -Nachrichten können über HTTP-Web-Sockets übertragen werden, um Push-Benachrichtigungen zu ermöglichen.

16
Glen Best

Async-Clients werden für WSDL-basierte Dienste durch die Verwendung von polling und callbacks unterstützt. In Ihrem Fall denke ich, dass die Anforderung relativ komplizierter ist.

Die Oracle-Fusion-Middleware Doc-Seite enthält ein Szenario, das Ihnen helfen wird. Sie beschreibt eine Methode, die Clients das Senden von Anforderungen ermöglicht, die ein HTTP 202 generieren (akzeptiert), und die Clients warten dann auf eine Antwort auf Nachrichtenwarteschlangen. In Ihrem Fall kann das Szenario von dem unten gezeigten abweichen.

Client callbacks

Initiieren Sie für jede Rückrufkategorie mehrere Antwortwarteschlangen. Die Clients können diese filtern, indem sie eine Client- und Kategorie-ID für die Warteschlange angeben. Dies dient als Rückrufmechanismus für jeden Client oder die Prozesse, die unter jedem Client geregelt werden. Die MDB kann durch einen Dateispeicher oder einen Datenbankspeicher gesichert werden, um Zuverlässigkeit und einmalige Bereitstellung zu gewährleisten.

Natürlich benötigen Sie keine Oracle-Fusionware, um dies zu implementieren. Sie können RabbitMQ oder Redis (mit Transaktionen) verwenden, um den Empfang einer Nachricht auf dem Client zu bestätigen. Wenn sich Ihr Client abmelden möchte, rufen Sie ihn an und hören Sie auf, die Warteschlange anzuhören. 

Ich kenne keinen Industriestandard, der in Ihr Szenario passt, aber ich glaube, dass diese Lösung für Sie gut funktionieren sollte.

7
Deepak Bala

Haben Sie sich über die einfachere Methode des "pub-sub" mit einem Messaging-Produkt Gedanken gemacht? (Wie MQ, EMS oder ActiveMQ)

Die von Ihnen beschriebenen Anforderungen scheinen nicht auf "klassische" Request/Reply-Synchronisierung/Async SOAP Web Service-Szenarien zu passen.

In einer Pub/Sub-Lösung abonnieren die Clients ein Thema einmal, und der Herausgeber (in Ihrem Fall der Server) kann eine beliebige Anzahl relevanter Nachrichten an alle Abonnenten senden.

Als Bonus bieten die meisten Messaging-Produkte Unterstützung für "dauerhafte Abonnenten", so dass der Client manchmal offline sein kann und alle Nachrichten nach der Neuverbindung empfangen kann.

In Ihrem Fall könnte der Server einen (kostenlosen) ActiveMQ-Server beherbergen ... der die meisten Funktionen bietet, die Sie suchen.

Wenn Sie so vorgehen, sollten Sie sich für ein JMS-kompatibles Produkt mit Unterstützung für .Net entscheiden.

5
GhislainCote

Für diejenigen, die von Suchmaschinen hierher kommen:

Sie können heutzutage einen WebHook für Web-APIs verwenden, der im Wesentlichen wie das beschriebene OP funktioniert.

In REST hat der Client beispielsweise einen HTTP-Endpunkt, der für den Empfang von POST Ereignissen/Benachrichtigungen vom tatsächlichen Server bestimmt ist. Der Client registriert seinen Endpunkt beim tatsächlichen Server, indem er ihm einen URI auf seinem Benachrichtigungsendpunkt gibt. Ab diesem Zeitpunkt kann der tatsächliche Server POST zum Benachrichtigungsendpunkt des Clients _ Wenn Sie mit der asynchronen Terminologie vertraut sind, handelt es sich im Wesentlichen um einen gefalteten Callback.

Vielleicht haben Java oder .Net inzwischen Bibliotheken für WebHooks.

Allerdings bieten die Standards SSEund Websockets aktuelle Push- und Echtzeitnachrichten, während sie mit HTTP und den meisten Browsern kompatibel sind.

In der Vergangenheit wurden auch lange Abstimmungsvariationen verwendet, die heute manchmal als Aggregat bezeichnet werden.

0
gabssnake