Warum sollten Sie SOAP über JSON und das benutzerdefinierte Datenformat in einer "ENTERPRISE" -Anwendung verwenden?

Question

Ich arbeite in einem mittelständischen Finanzunternehmen, in dem alle unsere Anwendungen über SOAP miteinander kommunizieren und wir nur JSON für AJAX-Anfragen von Websites verwenden.

Kürzlich fragte mich jemand in einer neuen Projektplanungssitzung, warum wir SOAP für die Kommunikation zwischen Anwendungen verwenden müssen. Warum nicht JSON oder gar ein benutzerdefiniertes Datenformat verwenden? In meinem Herzen fühlte ich, dass diese Alternativen nicht "unternehmensbereit" sind, aber ich konnte mir eigentlich keine sehr überzeugende Antwort darüber ausdenken, warum sie schlecht sind.

Die einzigen zwei Vorteile von SOAP, die ich mir vorstellen kann, sind Werkzeuge und Sicherheit.

Moderne IDEs wie Visual Studio verfügen über ein integriertes Dienstprogramm zum Generieren von Klassen aus WSDL-Definitionen, die Sie nicht erhalten, wenn Sie JSON oder ein benutzerdefiniertes Datenformat verwenden. Im Hinblick auf die Sicherheit verfügt SOAP über klar definierte Sicherheitsstandards, die in anderen Datenformatstandards nicht verfügbar sind.

Was denkst du? Verwenden Sie JSON als Datenaustauschformat zwischen Anwendungen?

Answer 1

IMHO gibt es einen großen Grund, warum jeder mit SOAP anstelle von JSON klebt. Mit jedem JSON-Setup erstellen Sie immer eine eigene Datenstruktur für jedes Projekt. Ich meine nicht, wie die Daten codiert und weitergegeben werden, sondern wie das Datenformat definiert ist, das Datenmodell.

SOAP hat eine ausgereifte Methode zur Angabe von Daten in der Form Cart ist eine Sammlung von Produkten und jedes Produkt kann diese Attribute usw. haben. Ein gut zusammengefügtes WSDL-Dokument hat das wirklich genagelt. Heck, es ist eine W3C-Spezifikation.

JSON hat ähnliche Möglichkeiten, diese Datenstruktur anzugeben. Eine JavaScript-Klasse kommt mir als die gebräuchlichste Methode in den Sinn.Eine JavaScript-Klasse ist nicht wirklich eine Datenstruktur in irgendeiner Art von agnostischer, gut etablierter und weit verbreiteter Art und Weise. Heck, JavaScript läuft wirklich nur in einer Umgebung, dem Browser.

Kurz gesagt, SOAP als eine Möglichkeit zur Angabe der Datenstruktur in einem reif formatierten Dokument (WSDL). JSON nicht.

UPDATE: Ich muss sagen, ich bin erstaunt über die Anzahl der Downstimmen, die diese Antwort im Laufe der Jahre erhalten hat, vor allem wegen ihrer Genauigkeit zu der Zeit. Ich will JSON nicht hassen, aber nach reading a recent article bleibe ich weiterhin bei meinen zuvor gemachten Punkten. In der Zwischenzeit scheint JSON-RPC praktisch von einer standardisierten Formatperspektive (Version 2.0 ein Vorschlag von 2010) und keine anderen JSON-Protokolle, die der SOAP-Standardisierung nahe kommen, aufgegeben zu werden. (Persönlich hat mich das nicht davon abgehalten JSON-RPC 2.0 in Produktionsumgebungen zu akzeptieren. Ich würde es niemals in einem Fortune 500-Unternehmen verwenden.)

Um klar zu sein, aus einer internen Sicht, JSON ist toll. Leicht. Schnell. Weit verbreitet. Ziemlich menschlich lesbar. Aber für Unternehmen, bei denen häufig mehrere Datenströme zusammengeführt werden. Und Datenformat-Spezifikation zwischen Dutzenden von Abteilungen ist notwendig. XML ist der etablierte Marktführer.

Answer 2

Der Grund für JSON ist Einfachheit. Es ist leicht zu lesen, leicht zu verstehen, hat wenig Overhead und hat Implementierungen in fast jeder Sprache.

Etwas etwas "Unternehmen" zu nennen ist etwas verrückt, IMHO. Es ist nur ein Datenaustauschformat. Ob SOAP, XML, JSON, was auch immer, es ist nur ein Kommunikationsformat.

Tooling ist nett, ich gebe zu; Automatisch generierte Klassen sind großartig. Aber auf der anderen Seite erhalten Sie eine Los Flexibilität, wenn Sie Ihre Klassen von Hand verwalten, und im Allgemeinen ist es nicht so schwierig zu tun.

Sicherheit ist kein Problem in meinem Kopf. Ihr Datenformat sollte (wiederum, IMHO) nichts mit Ihrer Sicherheit zu tun haben. Das muss ganz anders sein. Während SOAP einige Sicherheitserweiterungen hat, denke ich, dass sie größtenteils nur unnötige Komplexität bieten. Haben Sie schon einmal versucht, einige Spezifikationen für die WS-Sicherheit zu lesen? Huch. Wie wäre es nur mit JSON + HTTPS - einfach, jeder unterstützt es, und es funktioniert wie ein Champion ....

Nun, das ist nicht zu sagen, es ist die richtige Lösung für jedes Problem, aber wenn Sie nur suchen Datenaustausch, ich bin verkauft.

Persönlich liebe ich JSON als Format und benutze es die ganze Zeit.

Answer 3

JSON erfordert mehr Aufwand als SOAP XML, erzeugt aber normalerweise viel kleinere Pakete und ist daher besser skalierbar. Es ist auch (nach meiner subjektiven Meinung) wesentlich einfacher zu lesen, während das Debuggen, schnüffeln der Draht, etc.

Answer 4

Ein wichtiger Grund hat nichts mit technischen Gründen zu tun.

Viele "Enterprise" -Systeme werden an große, stickige "Enterprise" -Kunden verkauft. Der Kunde verlangt SOAP und das bekommen sie.

Was sind ihre Gründe? Manchmal ist es sehr pragmatisch: Ihr Team ist mit SOAP vertraut und es gibt viele existierende SOAP-Dienste (und dieses Team würde das Produkt nach der Lieferung warten). Manchmal ist es nicht so: Sie haben es in einem Artikel gelesen, und sie haben sich ihre Gedanken ausgedacht.

Answer 5

Ich würde SOAP nur verwenden, wenn die Daten groß oder ihre Struktur komplex ist. Der JSON, AJAX, PHP oder sogar der REST geht es gut.

Answer 6

Ich verwende SOAP, um von einem JavaEE (Jboss Ejb 3.1 @WebService) Backend zu MS C# Winforms zu kommunizieren.

Vielleicht wird es in Zukunft SOAP (Version X) geben, das komprimiertes JSON als Datenaustauschformat verwendet, das es schnell und ideal macht.

1. Restful ist gut für den einfachen Datenaustausch;
2. Ideal für Javascript Ajax Anfrage in einer interaktiven Webseite.