Erstens, ich beabsichtige keine Feindseligkeit oder Vernachlässigung, ich möchte nur die Gedanken der Menschen kennenlernen. Ich untersuche die bidirektionale Kommunikation zwischen Client und Server. Client ist eine Webanwendung. An diesem Punkt habe ich ein paar Optionen: MS-proprietäre Duplex-Bindung, von dem, was ich unzuverlässig und unnatürlich höre: Kometen 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 zu dem Ansatz. Betrachtet man Web-Sockets auf Client-Seite, so sitzt der Client-Code in JavaScript. Ist es wirklich die Absicht, einen großen Teil einer Anwendung direkt in JavaScript zu erstellen? Warum hat W3C das nicht in Webdiensten gemacht? Wäre es nicht einfacher, wenn wir in der Lage wären, SOAP für die Bereitstellung eines Vertrags und die Definition von Ereignissen zusammen mit dem vorhandenen Messaging zu verwenden? Fühlt sich einfach wie das kurze Ende des Stocks an.
Warum machen Sie es nicht einfach und nutzen Sie die dynamische JS-Natur und lassen Sie den Großteil des Codes dort, wo er hingehört .... auf dem Server?
Anstelle von
%Vor%könnten wir sagen
%Vor%und statt
%Vor%könnten wir sagen
%Vor%HTML 5 hat ewig gebraucht ... haben wir eine Menge Aufwand in die falsche Richtung verschwendet? Gedanken?
Klingt für mich so, als ob Sie die Konzepte von Websockets noch nicht vollständig begriffen hätten. Zum Beispiel sagst du:
Betrachtet man Web-Sockets sind Client-Seite
Das ist nicht der Fall, Sockets haben zwei Seiten, man könnte sich diese als Server und Client vorstellen, aber sobald die Verbindung hergestellt ist, verschwimmt die Unterscheidung - man könnte sich dann auch den Client und den Server als "Peers" vorstellen "- Jeder kann zu jeder Zeit in die Pipe schreiben oder einlesen, die sie verbindet (die Socket-Verbindung). Ich vermute, dass Sie davon profitieren würden, etwas mehr über HTTP zu lernen, das über TCP hinausgeht - WebSockets ist auf diese Weise ähnlich / analog zu HTTP.
In Bezug auf SOAP / WSDL können Sie aus Sicht einer Konversation, die TCP / WebSocket / HTTP umgibt, alle SOAP / WSDL-Konversationen als identisch mit HTTP (d. h. normaler Webseitenverkehr) ansehen.
Merken Sie sich schließlich die gestapelte Art der Netzwerkprogrammierung, zum Beispiel sieht SOAP / WSDL wie folgt aus:
%Vor%Und WebSockets sehen so aus
%Vor%HTH.
JavaScript ermöglicht Clients die Kommunikation über HTTP mit XMLHttpRequest. WebSockets erweitert diese Funktionalität, sodass JavaScript beliebige Netzwerk-E / A (nicht nur HTTP) ausführen kann. Dies ist eine logische Erweiterung und ermöglicht die Portierung aller Arten von Anwendungen, die TCP-Datenverkehr verwenden müssen (möglicherweise jedoch nicht das HTTP-Protokoll verwenden) zu JavaScript. Ich denke, es ist ziemlich logisch, dass HTML und JavaScript alles unterstützen, was auf dem Desktop verfügbar ist, da Anwendungen weiterhin in die Cloud verschoben werden.
Während ein Server im Auftrag eines JavaScript-Clients nicht-HTTP-Netzwerk-E / A ausführen kann und diese Kommunikation über HTTP verfügbar macht, ist dies nicht immer die geeignetste oder effizienteste Vorgehensweise. Es wäre beispielsweise nicht sinnvoll, beim Versuch, ein Online-SSH-Terminal zu erstellen, zusätzliche Round-Trip-Kosten hinzuzufügen. WebSockets ermöglicht es, dass JavaScript direkt mit dem SSH-Server kommuniziert.
Wie für die Syntax basiert ein Teil davon auf XMLHttpRequest. Wie in dem anderen Beitrag erwähnt wurde, ist WebSockets eine API auf ziemlich niedriger Ebene, die in eine verständlichere eingebettet werden kann. Es ist wichtiger, dass WebSockets alle notwendigen Anwendungen unterstützt, als dass sie die eleganteste Syntax haben (manchmal kann die Konzentration auf die Syntax zu restriktiveren Funktionen führen). Bibliotheksautoren können diese sehr allgemeine API für andere Anwendungsentwickler immer besser verwalten.
Wie Sie festgestellt haben, hat WebSockets geringen Overhead . Der Aufwand ist ähnlich wie bei normalen TCP-Sockets: nur zwei Bytes mehr pro Frame im Vergleich zu Hunderten für AJAX / Comet.
Warum Low-Level anstelle einer integrierten RPC-Funktionalität? Einige Gedanken:
Es ist nicht so schwer, ein existierendes RPC-Protokoll und layer it auf einem Low-Level-Socket-Protokoll zu verwenden. Sie können nicht die umgekehrte Richtung wählen und eine Low-Level-Verbindung aufbauen, wenn der RPC-Overhead angenommen wird.
Die Unterstützung von WebSockets ist ziemlich trivial , um sie auf der Serverseite mehreren Sprachen hinzuzufügen. Die Nutzlast ist nur eine UTF-8-Zeichenfolge und so ziemlich jede Sprache verfügt über eine 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 Typ Hinting auf der Javascript-Seite hinzufügen? Was ist mit Variablen Länge Argumente und / oder Argumentlisten? Bauen Sie diese Mechanismen auf, wenn die Sprache keine gute Antwort hat? Etc.
Welchen RPC-Mechanismus würde es nachbilden? Würdest du ein bestehendes wählen (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) oder ein völlig neues?
Sobald die Client-Unterstützung ziemlich universell ist, werden viele Dienste mit normalem TCP-Socket WebSockets-Unterstützung hinzufügen (weil es ziemlich trivial ist, sie hinzuzufügen). Dasselbe gilt nicht, wenn WebSockets RPC-basiert war. Einige vorhandene Dienste fügen möglicherweise eine RPC-Ebene hinzu, aber die WebSockets-Dienste werden größtenteils von Grund auf neu erstellt.
Für mein Projekt noVNC (VNC-Client, der nur Javascript, Canvas, WebSockets verwendet) ist die geringe Overhead-Eigenschaft von WebSockets entscheidend für Erreichen einer angemessenen Leistung. Bis VNC-Server die WebSockets-Unterstützung enthalten, enthält noVNC wsproxy, einen generischen WebSockets-zu-TCP-Socket-Proxy.
Wenn Sie über die Implementierung einer interaktiven Webanwendung nachdenken und sich nicht für die serverseitige Sprache entschieden haben, sollten Sie sich ansehen Socket.IO , das eine Bibliothek für Knoten ist (serverseitiges JavaScript mit der Google-V8-Engine).
Zusätzlich zu all den Vorteilen von node (gleiche Sprache auf beiden Seiten, sehr effizient, Power-Bibliotheken, etc.), Socket.IO gibt Ihnen mehrere Dinge:
Bietet sowohl die Client- als auch die Server-Framework-Bibliothek zum Behandeln von Verbindungen.
Erkennt den besten Transport, der von Client und Server unterstützt wird. Zu den Transporten gehören (vom besten zum schlechtesten): native WebSockets, WebSockets mit Flash-Emulation, verschiedene AJAX-Modelle.
Konsistente Schnittstelle, egal welcher Transport verwendet wird.
Automatische Kodierung / Dekodierung von Javascript-Datentypen.
Es wäre nicht schwer, einen RPC-Mechanismus über Socket.IO zu erstellen, da beide Seiten die gleiche Sprache mit den gleichen nativen Typen haben.
WebSocket macht Comet und alle anderen HTTP-Push-Techniken lesbar, indem Anfragen vom Server stammen. Es ist eine Art Sandbox-Socket und gibt uns eingeschränkte Funktionalität.
Die API ist jedoch allgemein genug, damit Framework- und Bibliotheksautoren die Schnittstelle auf jede gewünschte Art und Weise verbessern können. Sie könnten beispielsweise einen RPC- oder RMI-Dienst auf WebSockets schreiben, der das Senden von Objekten über die Verbindung ermöglicht. Jetzt werden sie intern in einem unbekannten Format serialisiert, aber der Dienstbenutzer muss es nicht wissen und kümmert sich nicht darum.
Also denke ich von einem Spezifikationsautoren-POV, der von
geht %Vor%bis
%Vor%ist vergleichsweise einfach und erfordert das Schreiben eines kleinen Wrappers um WebSockets, sodass die Serialisierung und Deserialisierung undurchsichtig für die Anwendung erfolgt. Aber in umgekehrter Richtung bedeutet, dass die Spezifikationsautoren eine viel komplexere API erstellen müssen, die eine schwächere Grundlage für das Schreiben von Code darüber bildet.
Ich stieß auf das gleiche Problem, wo ich etwas wie call('AFunction', 'foo', 'bar') machen musste, anstatt jede Interaktion serialisieren / de-serialisieren zu müssen. Meine Vorliebe war auch, den Großteil des Codes auf dem Server zu belassen und nur das Javascript zu verwenden, um die Ansicht zu behandeln. WebSockets waren aufgrund ihrer natürlichen Unterstützung für bidirektionale Kommunikation besser geeignet. Um meine App-Entwicklung zu vereinfachen, erstelle ich eine Schicht über WebSockets, um Remote-Methodenaufrufe durchzuführen (wie RPC ).
Ich habe die RMI/RPC -Bibliothek unter Ссылка veröffentlicht. Sobald die Kommunikation zwischen der Webseite und dem Servlet eingerichtet ist, können Sie Anrufe in beide Richtungen ausführen. Der Server verwendet Reflektion, um die entsprechende Methode im serverseitigen Objekt aufzurufen, und der Client verwendet die Aufrufmethode von JavaScript, um die entsprechende Funktion im clientseitigen Objekt aufzurufen. Die Bibliothek verwendet Jackson , um sich um die Serialisierung / Deserialisierung verschiedener Java-Typen zu / von JSON zu kümmern.
WebSocket JSR wurde von einer Reihe von Parteien (Oracle, Apache, Eclipse usw.) ausgehandelt, die alle sehr unterschiedliche Agenden hatten. Es ist genauso gut, dass sie auf der Ebene des Nachrichtentransports aufhörten und Konstrukte höherer Ebene ausließen. Wenn Sie eine Java-zu-JavaScript-RMI benötigen, lesen Sie das FERMI-Framework .