Architect möchte unbedingt SOAP über JMS verwenden

Java

Ich habe in der Vergangenheit JMS verwendet, um Anwendungen zu erstellen, und es funktioniert großartig. Jetzt arbeite ich mit Architekten zusammen, die gerne die Spezifikation :SOAP über Java Message Service 1.0 verwenden würden.

Diese Spezifikation erscheint übermäßig kompliziert. Ich sehe nicht viele Implementierungen (abgesehen von den Anbietern, die auf die Spezifikation drängen).

Verwendet hier jemand diese Spezifikation in einer Produktionsumgebung? Was ist Ihr Hauptvorteil bei der Verwendung dieser Spezifikation?

Link:http://www.w3.org/TR/2009/CR-soapjms-20090604/

Antwort

Ich hatte das Pech mit SOAP über JMS. Es ist sinnvoll, wenn es für Fire-and-Forget-Operationen verwendet wird (keine Antwortnachricht in der WSDL definiert). In diesem Fall können Sie die WSDL verwenden, um Client-Skeletts zu generieren, und Sie können die WSDL in Ihrer Dienstregistrierung speichern. Außerdem erhalten Sie alle üblichen Vorteile von JMS (Entkopplung von Sender und Empfänger, Lastausgleich, Priorisierung, Sicherheit, Überbrückung zu mehreren Zielen – z. B. nicht-intrusives Auditing).

Andererseits wird SOAP hauptsächlich für Request/Reply-Operationen verwendet. Das Implementieren von Anforderungs-/Antwortmustern über JMS führt zu folgenden Problemen:

Es ist unmöglich, Zeitüberschreitungen richtig zu handhaben. Man weiß nie, ob eine Anfrage noch auf Zustellung wartet oder in der aufgerufenen Komponente hängen geblieben ist.
Antworten werden normalerweise an temporäre Warteschlangen gesendet. Wenn der Client die Verbindung trennt, bevor er die Antwort erhält, und in der Antwortnachricht keine explizite Gültigkeitsdauer festgelegt ist, kann die temporäre Warteschlange im JMS-Server hängen bleiben, bis Sie sie neu starten.
Ein JMS-Server in der Mitte erhöht die Roundtrip-Zeiten dramatisch und fügt unnötige Komplexität hinzu.
JMS bietet ein zuverlässiges Transportmedium, das den Sender vom Empfänger entkoppelt, aber im Falle einer Anfrage/Antwort sollte der Client nicht vom Server entkoppelt werden. Der Client muss wissen, ob der Server aktiv und verfügbar ist.

Der einzige Vorteil, an den ich denken könnte, ist, dass der Server verschoben oder belastet werden kann, ohne dass der Client davon weiß, aber die Verwendung von UDDI und HTTP-Load-Balancer ist eine bessere Lösung.