Architect möchte dringend SOAP über JMS verwenden

Ich hatte das Pech mit SOAP über JMS. Es macht Sinn, wenn es für Fire-and-Forget-Operationen verwendet wird (keine in der WSDL definierte Antwortnachricht). In diesem Fall können Sie mithilfe der WSDL Clientskelette generieren und die WSDL in Ihrer Serviceregistrierung speichern. Außerdem erhalten Sie alle üblichen Vorteile von JMS (Entkoppeln von Sender und Empfänger, Lastenausgleich, Priorisierung, Sicherheit, Überbrückung zu mehreren Zielen - z. B. nicht-intrusive Auditing).

Auf der anderen Seite wird SOAP hauptsächlich für Anfragen / Antworten verwendet. Das Implementieren des Anfrage- / Antwortmusters über JMS führt zu folgenden Problemen:

• Zeitüberschreitungen können nicht korrekt verarbeitet werden. Sie wissen nie, ob eine Anfrage immer noch auf die Zustellung wartet oder in der aufgerufenen Komponente steckengeblieben ist.
• Antworten werden normalerweise in temporären Warteschlangen gesendet. Wenn der Client die Verbindung trennt, bevor die Antwort empfangen wird, und keine explizite Lebenszeit für die Antwortnachricht festgelegt wird, kann die temporäre Warteschlange im JMS-Server hängen bleiben, bis Sie sie erneut starten.
• Wenn Sie einen JMS-Server in der Mitte haben, werden die Roundtrip-Zeiten dramatisch erhöht und unnötige Komplexität hinzugefügt.
• JMS stellt ein zuverlässiges Transportmedium zur Verfügung, 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 verfügbar und verfügbar ist.

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

Ich würde sagen, dass von der Suche eines Architekten die gleiche Frage wäre, warum man ein 5-schichtiges Internetmodell hat, wobei die fünfte die Anwendung ist, wenn man einfach die gesamte Anwendung auf Sockelebene codieren könnte. Die Transportschicht (JMS in Ihrem Fall) aus dem, was Ihre Anwendung produziert oder konsumiert (SOA-Nachrichten) zu abstrahieren, ist eine gute Praxis für viele Gründe, von denen unabhängige Komponententests und zukünftige Migration auf andere Plattformen die ersten sind

Verdammt, ich hasse es, mit Architect Astronauts zu arbeiten. Ich fühle deinen Schmerz Bruder. Haben sie tatsächlich einen tatsächlichen, funktionalen Grund dafür, außer "es ist ein Standard"? Wird diese Entscheidung sie in einen bestimmten EE-Container-Anbieter sperren (sagen wir WebSphere)? Das ist so 2002; sehr wenige Leute haben ein echtes Bedürfnis dafür; Tatsächlich wurde SOAP von den meisten praktischen, erfolgreichen Implementierungen ziemlich ignoriert. Wenn sie nicht wirklich mehr Zuverlässigkeit benötigen, als sie von JMS oder SOAP-über-HTTP allein zur Verfügung gestellt wird, sind Sie auf einer Reise.

Überprüfen Sie die Site von Apache CFX auf einige Beispiele (spezifisch für CFX).

Ссылка

Die Faustregel wäre, wirklich das Minimum zu verwenden und nicht den vollen Stack. Wenn deine Architekten-Astronauten immer noch darauf bestehen, das Ganze zu benutzen, wirst du vielleicht in eine Welt voller Schmerzen gehen. Entschuldigung.

BEARBEITEN:

Übrigens, welchen Anwendungscontainer verwenden Sie? WebLogic, JBoss, WebSphere? Und welches Webservice-Framework? Apache CFX, Achse?

Architekten Astronauten werden gerne sagen, dass das Implementierungsdetails sind. Stier. Jede Entscheidung über ein System, dessen Änderung hohe Kosten verursacht (oder deren Implementierung erhebliche Einsparungen bringt), ist eine architektonische Entscheidung. Diese diktieren ziemlich genau, wie die Dinge implementiert werden (und was die Kosten der Veränderung sein werden). Daher ist es eine architektonische Entscheidung, früh zu entscheiden, welche Architektur Sie verwenden, außer mit sehr eigenständigen Systemen.

Einige weitere Links zu diesem kontroversen Thema:

Ссылка Ссылка

Image Sie haben einen häufig verwendeten Web-Service implementiert neigt dazu, von Threads zu laufen, während Sie versprochen haben, dass keine Nachricht wird verloren sein.

Eine Webservice-Implementierung (der Server), die über eine Session - Bean kommt mit einer begrenzten Anzahl von Threads (sagen wir n aktives PE in Ihrem Pool), das möglicherweise eine Web-Service-Anfrage ausführt gleichzeitig. Was passiert mit der n + 1 Anfrage?

MRDE, haben Sie nicht Ihnen Anwendungsinhaber versprochen, dass nein? Nachricht wird verloren gehen. Das JMS isoliert diese Funktionalität also. Das Webservice-Skelett muss die Daten nur in einer Warteschlange speichern. und das gibt Zuverlässigkeit auch in Bezug auf Lastspitzen.

Das Interessante an WS über JMS ist, dass die verstrichene Zeit einer laufenden WS-Anfrage ist ziemlich kurz, so dass der Rechenaufwand sinkt wird sofort die nächste Anfrage an den Server zurückgeben.