Warum verwenden Web Sockets kein SOAP?

Question

Zunächst einmal möchte ich weder Feindseligkeit noch Nachlässigkeit zeigen, sondern nur die Gedanken der Menschen kennen.Ich untersuche die bidirektionale Kommunikation zwischen Client und Server.Der Client ist eine Webanwendung.An dieser Stelle habe ich einige Möglichkeiten:MS-proprietäre Duplexbindung, soweit ich gehört habe, unzuverlässig und unnatürlich:Comet und Web Sockets (für unterstützte Browser).

Ich weiß, dass diese Frage hier auf andere Weise gestellt wurde, aber ich habe eine spezifischere Frage zum Ansatz.Da Web-Sockets clientseitig sind, befindet sich der Client-Code in JavaScript.Ist es wirklich die Absicht, einen großen Teil einer Anwendung direkt in JavaScript zu erstellen?Warum hat W3C dies nicht in Webdiensten getan?Wäre es nicht einfacher, wenn wir SOAP verwenden könnten, um einen Vertrag bereitzustellen und Ereignisse zusammen mit den vorhandenen Nachrichten zu definieren?Fühlt sich bisher einfach so an, als ob ich den Kürzeren gezogen hätte.

Warum machen Sie es sich nicht einfach, nutzen die dynamische Natur von JS und belassen den Großteil des Codes dort, wo er hingehört ... auf dem Server?

Anstatt

mysocket.send("AFunction|withparameters|segmented");

könnten wir sagen

myServerObject.AFunction("that", "makessense");

und statt

...
mysocket.onmessage = function() { alert("yay! an ambiguous message"); }
...

könnten wir sagen

...
myServerObject.MeaningfulEvent = function(realData) { alert("Since I have realistic data....");  alert("Hello " + realData.FullName); }
...

Es hat ewig gedauert, bis sich HTML 5 durchgesetzt hat. Haben wir große Anstrengungen in die falsche Richtung verschwendet?Gedanken?

Answer 1

Klingt für mich so, als hätten Sie die Konzepte rund um Websockets noch nicht vollständig erfasst. Zum Beispiel sagen Sie:

Wenn man in Betracht zieht, sind Web-Sockets clientseitig

Dies ist nicht so Kann das Rohr schreiben oder lesen, das sie jederzeit verbindet (die Sockelverbindung). Ich vermute, Sie würden davon profitieren, ein wenig mehr über HTTP -Arbeiten auf TCP zu lernen - WebSockets ist auf diese Weise ähnlich / analog für HTTP.

In Bezug auf SOAP / WSDL können Sie sich aus der Sicht eines Gesprächs über TCP / WebSocket / HTTP alle SOAP / WSDL -Gespräche als identisch mit HTTP (dh normaler Webseitenverkehr) vorstellen.

Denken Sie schließlich an die gestapelte Natur der Netzwerkprogrammierung, beispielsweise SOAP/WSDL sieht Folgendes aus:

SOAP/WSDL
--------- (sits atop)
HTTP
--------- (sits atop)
TCP

Und Websockets sehen so aus

WebSocket
--------- (sits atop)
TCP

HTH.

Answer 2

Mit JavaScript können Clients über http mit xmlHttprequest kommunizieren. WebSockets erweitert diese Funktionalität, damit JavaScript ein beliebiges Netzwerk -E/A (nicht nur HTTP) erstellen kann, was eine logische Erweiterung ist und alle Arten von Anwendungen ermöglicht, die den TCP -Datenverkehr verwenden müssen (aber möglicherweise nicht das HTTP -Protokoll verwenden) portiert werden müssen nach JavaScript. Ich denke, es ist eher logisch, dass HTML und JavaScript, wenn Anwendungen weiter in die Cloud wechseln, alles unterstützen, was auf dem Desktop verfügbar ist.

Während ein Server im Namen eines JavaScript-Clients nicht-HTTP-Netzwerk-E/A durchführen und diese Kommunikation über HTTP verfügbar machen, ist dies nicht immer das geeignete oder effizienteste, was zu tun ist. Zum Beispiel wäre es nicht sinnvoll, beim Versuch, ein Online-SSH-Terminal zu erstellen, zusätzliche Roundtripskosten hinzuzufügen. WebSockets ermöglicht es JavaScript, direkt mit dem SSH -Server zu sprechen.

Was die Syntax betrifft, basiert ein Teil davon auf XMLHTTPrequest. Wie in der anderen Posting hervorgeht, ist Websockets eine ziemlich niedrige API, die in einem verständlicheren umwickelt werden kann. Es ist wichtiger, dass WebSockets alle erforderlichen Anwendungen unterstützt, als dass es die eleganteste Syntax aufweist (manchmal kann der Schwerpunkt auf die Syntax zu restriktiveren Funktionen führen). Bibliotheksautoren können diese sehr allgemeine API für andere Anwendungsentwickler immer besser überschaubar machen.

Answer 3

Wie Sie bemerkt haben, hat WebSockets dies getan geringer Overhead.Der Overhead ist ähnlich wie bei normalen TCP-Sockets:nur zwei Bytes mehr pro Frame im Vergleich zu Hunderten bei AJAX/Comet.

Warum Low-Level statt irgendeiner integrierten RPC-Funktionalität?Einige Gedanken:

• Es ist nicht so schwer, ein vorhandenes RPC-Protokoll zu übernehmen schichte es auf einem Low-Level-Socket-Protokoll.Sie können nicht in die entgegengesetzte Richtung gehen und eine Low-Level-Verbindung aufbauen, wenn der RPC-Overhead angenommen wird.

• WebSockets-Unterstützung ist ziemlich trivial um mehrere Sprachen auf der Serverseite hinzuzufügen.Die Nutzlast ist nur eine UTF-8-Zeichenfolge und praktisch jede Sprache verfügt über eine integrierte effiziente Unterstützung dafür.Ein RPC-Mechanismus nicht so sehr.Wie gehen Sie mit Datentypkonvertierungen zwischen Javascript und der Zielsprache um?Müssen Sie auf der Javascript-Seite Typhinweise hinzufügen?Was ist mit Argumenten variabler Länge und/oder Argumentlisten?Bauen Sie diese Mechanismen auf, wenn die Sprache keine gute Antwort hat?Usw.

• Welchem ​​RPC-Mechanismus würde es nachempfunden sein?Würden Sie sich für ein bestehendes (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) oder ein völlig neues entscheiden?

• Sobald die Client-Unterstützung einigermaßen universell ist, werden viele Dienste, die über einen normalen TCP-Socket verfügen, WebSockets-Unterstützung hinzufügen (da das Hinzufügen ziemlich einfach ist).Das Gleiche gilt nicht, wenn WebSockets RPC-basiert wäre.Einige bestehende Dienste fügen möglicherweise eine RPC-Schicht hinzu, aber die meisten WebSockets-Dienste würden von Grund auf neu erstellt.

Für mein noVNC Projekt (VNC-Client, der nur Javascript, Canvas, WebSockets verwendet) ist der geringe Overhead von WebSockets entscheidend für das Erreichen einer angemessenen Leistung.Bis VNC-Server WebSockets-Unterstützung bieten, enthält noVNC wsproxy, einen generischen WebSockets-zu-TCP-Socket-Proxy.

Wenn Sie über die Implementierung einer interaktiven Webanwendung nachdenken und sich noch nicht für eine serverseitige Sprache entschieden haben, empfehle ich Ihnen, einen Blick darauf zu werfen Socket.IO Das ist eine Bibliothek für Knoten (serverseitiges Javascript unter Verwendung der V8-Engine von Google).

Zusätzlich zu allen Vorteilen von Node (gleiche Sprache auf beiden Seiten, sehr effizient, leistungsstarke Bibliotheken usw.) bietet Ihnen Socket.IO mehrere Dinge:

• Stellt sowohl eine Client- als auch eine Server-Framework-Bibliothek für die Verarbeitung von Verbindungen bereit.

• Erkennt den besten Transport, der sowohl vom Client als auch vom Server unterstützt wird.Zu den Transporten gehören (vom Besten zum Schlechtesten):native WebSockets, WebSockets mit Flash-Emulation, verschiedene AJAX-Modelle.

• Konsistente Schnittstelle, unabhängig vom verwendeten Transportmittel.

• Automatische Kodierung/Dekodierung von Javascript-Datentypen.

Es wäre nicht so schwer, einen RPC-Mechanismus auf Socket.IO zu erstellen, da beide Seiten dieselbe Sprache mit denselben nativen Typen verwenden.

Answer 4

WebSocket macht Comet und alle anderen HTTP -Pushtyp -Techniken lesbar, indem sie Anforderungen ermöglicht, vom Server zu stammen. Es ist eine Art Sandbox -Sockel und gibt uns begrenzte Funktionen.

Die API ist jedoch allgemein genug, damit Framework- und Bibliotheksautoren die Schnittstelle auf die gewünschte Weise verbessern können. Sie können beispielsweise einen RPC- oder RMI -gestylerischen Dienst über WebSockets schreiben, mit dem Objekte über das Kabel gesendet werden können. Jetzt werden sie intern in einem unbekannten Format serialisiert, aber der Service -Benutzer muss es nicht wissen und kümmert sich nicht darum.

Also denken

mysocket.send("AFunction|withparameters|segmented");

zu

myServerObject.AFunction("that", "makessense");

ist vergleichsweise einfach und erfordert das Schreiben einer kleinen Wrapper um Websockets, damit die Serialisierung und Deserialisierung ein undurchsichtiges zur Anwendung geschieht. Wenn Sie jedoch in die umgekehrte Richtung gehen, müssen die Spec -Autoren eine viel komplexere API erstellen, die eine schwächere Grundlage für das Schreiben von Code darüber liefert.

Answer 5

Ich stieß auf das gleiche Problem, wo ich so etwas tun musste call('AFunction', 'foo', 'bar') anstatt jede Wechselwirkung zu serialisieren/zu serialisieren. Meine Präferenz war auch, den Großteil des Codes auf dem Server zu lassen und einfach das JavaScript zu verwenden, um die Ansicht zu verarbeiten. Websockets passten aufgrund seiner natürlichen Unterstützung für die bidirektionale Kommunikation besser. Um meine App -Entwicklung zu vereinfachen, erstelle ich eine Ebene über Websockets, um Remote -Methodenaufrufe zu tätigen (wie wie RPC).

Ich habe das veröffentlicht RMI/RPC Bibliothek bei http://sourceforge.net/projects/rmiwebsocket/. Sobald die Kommunikation zwischen der Webseite und dem Servlet eingerichtet ist, können Sie Anrufe in beide Richtungen ausführen. Der Server verwendet Reflection, um die entsprechende Methode im serverseitigen Objekt aufzurufen, und der Client verwendet die "Call" -Methode von JavaScript, um die entsprechende Funktion im clientseitigen Objekt aufzurufen. Die Bibliothek verwendet Jackson Pflege der Serialisierung/Deserialisierung verschiedener Java -Typen von JSON.

Answer 6

WebSocket JSR wurde von einer Reihe von Parteien (Oracle, Apache, Eclipse usw.) mit sehr unterschiedlichen Agenden ausgehandelt. Es ist genauso gut, dass sie auf dem Message Transport Level angehalten haben und höhere Konstrukte auf dem Stufe hinterlassen haben. Wenn Sie einen Java zu JavaScript RMI brauchen, schauen Sie sich das an die Fermi -Framework.