¿Por qué los enchufes web no usan jabón?

Question

En primer lugar, tengo la intención de que no haya hostilidad ni neglegencia, solo quiero conocer los pensamientos de las personas. Estoy investigando la comunicación bidireccional entre el cliente y el servidor; cliente es una aplicación web. En este punto, tengo algunas opciones: enlace dúplex de MS-propietario, de lo que escucho poco confiable y antinatural: cometa y enchufes web (para navegadores compatibles).

Sé que esta pregunta se ha hecho de otras maneras aquí, pero tengo una pregunta más específica para el enfoque. Teniendo en cuenta que los sockets web son del lado del cliente, el código del cliente se encuentra en JavaScript. ¿Es realmente la intención de construir una gran parte de una aplicación directamente en JavaScript? ¿Por qué W3C no hizo esto en los servicios web? ¿No sería más fácil si pudiéramos usar SOAP para proporcionar un contrato y definir eventos junto con los mensajes existentes involucrados? Simplemente se siente como el extremo corto del palo hasta ahora.

¿Por qué no hacerlo simple y aprovechar la naturaleza dinámica JS y dejar la mayor parte del código donde pertenece ... en el servidor?

En vez de

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

Podríamos decir

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

y en lugar de

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

Podríamos decir

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

HTML 5 tardó una eternidad en afianzarse ... ¿desperdiciamos una gran cantidad de esfuerzo en la dirección equivocada? ¿Pensamientos?

Answer 1

Me parece que aún no has comprendido por completo los conceptos en torno a las redes web. Por ejemplo, dices:

Teniendo en cuenta que los enchufes web son del lado del cliente

Este no es el caso, los sockets tienen 2 lados, se puede pensar en estos como un servidor y un cliente, sin embargo, una vez que se establece la conexión, la distinción se desenlace, también podría pensar en el cliente y el servidor como "pares", cada uno. Puede escribir o leer en la tubería que los conecta (la conexión del socket) en cualquier momento. Sospecho que se beneficiaría de aprender un poco más sobre los trabajos HTTP sobre TCP: WebSockets es similar / análogo a HTTP de esta manera.

Con respecto a SOAP / WSDL, desde el punto de vista de una conversación que rodea TCP / WebSocket / HTTP, puede pensar que todas las conversaciones SOAP / WSDL son idénticas a HTTP (es decir, el tráfico normal de la página web).

Finalmente, recuerde la naturaleza apilada de la programación de red, por ejemplo, SOAP/WSDL se ve así:

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

Y los websockets se ven así

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

Hth.

Answer 2

JavaScript permite a los clientes comunicarse a través de HTTP con XMLHTTPREQUEST. WebSockets extiende esta funcionalidad para permitir que JavaScript realice una E/S de red arbitraria (no solo HTTP), que es una extensión lógica y permite que todo tipo de aplicaciones que necesitan usar el tráfico TCP (pero que podrían no estar utilizando el Protocolo HTTP) para ser portado a JavaScript. Creo que es bastante lógico que, a medida que las aplicaciones continúan pasando a la nube, que HTML y JavaScript admitan todo lo que está disponible en el escritorio.

Si bien un servidor puede hacer E/S de red no HTTP en nombre de un cliente JavaScript y hacer que esa comunicación esté disponible a través de HTTP, esto no siempre es lo más apropiado o eficiente. Por ejemplo, no tendría sentido agregar un costo adicional de ida y vuelta al intentar hacer una terminal SSH en línea. WebSockets hace posible que JavaScript hable directamente con el servidor SSH.

En cuanto a la sintaxis, parte de ella se basa en xmlhttprequest. Como se ha señalado en la otra publicación, WebSockets es una API de bajo nivel que se puede envolver en una más comprensible. Es más importante que WebSockets admite todas las aplicaciones necesarias que que tenga la sintaxis más elegante (a veces centrarse en la sintaxis puede conducir a una funcionalidad más restrictiva). Los autores de la biblioteca siempre pueden hacer que esta API muy general sea más manejable para otros desarrolladores de aplicaciones.

Answer 3

Como señaló que WebSockets tiene gastos indirectos bajos. La sobrecarga es similar a los enchufes TCP normales: solo dos bytes más por cuadro en comparación con cientos para AJAX/Comet.

¿Por qué de bajo nivel en lugar de algún tipo de funcionalidad RPC incorporada? Algunos pensamientos:

• No es tan difícil tomar un protocolo RPC existente y Coloque en un protocolo de socket de bajo nivel. No puede ir en la dirección opuesta y construir una conexión de bajo nivel si se supone la sobrecarga RPC.

• Soporte de WebSockets es bastante trivial Para agregar a varios idiomas en el lado del servidor. La carga útil es solo una cadena UTF-8 y casi todos los idiomas tienen un soporte eficiente incorporado para eso. Un mecanismo RPC no tanto. ¿Cómo maneja las conversiones de tipo de datos entre JavaScript y el idioma de destino? ¿Necesita agregar un tipo de sugerencias en el lado de JavaScript? ¿Qué pasa con los argumentos de longitud variable y/o listas de argumentos? ¿Construyes estos mecanismos si el lenguaje no tiene una buena respuesta? Etc.

• ¿Qué mecanismo RPC se modelará después? ¿Elegiría uno existente (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPYC, CORBA) o uno completamente nuevo?

• Una vez que el soporte del cliente es bastante universal, muchos servicios que tienen un socket TCP normal agregarán soporte WebSockets (porque es bastante trivial de agregar). Lo mismo no es cierto si WebSockets se basó en RPC. Algunos servicios existentes pueden agregar una capa RPC, pero en su mayor parte los servicios de WebSockets se crearían desde cero.

Para mi novnc Proyecto (Cliente VNC que usa Just JavaScript, Canvas, WebSockets) La naturaleza de bajo nivel de WebSockets es fundamental para lograr un rendimiento razonable. Hasta que los servidores VNC incluyan el soporte de WebSockets, NovNC incluye WSProxy, que es un proxy de Socket de TCP.

Si está pensando en implementar una aplicación web interactiva y no se ha decidido por el lenguaje del lado del servidor, entonces sugiero ver Socket.io que es una biblioteca para nodo (JavaScript del lado del servidor usando el motor V8 de Google).

Además de todas las ventajas del nodo (el mismo lenguaje en ambos lados, bibliotecas de energía muy eficientes, etc.), Socket.io le da varias cosas:

• Proporciona la biblioteca del marco del cliente y del servidor para el manejo de conexiones.

• Detecta el mejor transporte compatible con el cliente y el servidor. Los transportes incluyen (de lo mejor a peor): WebSockets nativos, WebSockets con emulación flash, varios modelos AJAX.

• Interfaz consistente sin importar qué transporte se utilice.

• Codificación/decodificación automática de los tipos de datos JavaScript.

No sería tan difícil crear un mecanismo RPC en la parte superior de Socket.io, ya que ambos lados son el mismo idioma con los mismos tipos nativos.

Answer 4

WebSocket hace que Comet y todas las demás técnicas de tipo de empuje HTTP legible al permitir que las solicitudes se originen en el servidor. Es una especie de enchufe de arena y nos da una funcionalidad limitada.

Sin embargo, la API es lo suficientemente general para que los autores de marco y biblioteca mejoren en la interfaz de la manera que deseen. Por ejemplo, puede escribir algún servicio de estilo RPC o RMI en la parte superior de WebSockets que permite enviar objetos a través del cable. Ahora internamente están siendo serializados en algún formato desconocido, pero el usuario del servicio no necesita saber y no le importa.

Entonces, pensar en un autores de especificaciones POV, yendo de

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

a

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

es relativamente fácil y requiere escribir un envoltorio pequeño alrededor de WebSockets para que la serialización y la deserialización ocurran opaciamente en la aplicación. Pero ir en la dirección inversa significa que los autores de especificaciones deben hacer una API mucho más compleja que lo convierte en una base más débil para escribir código además.

Answer 5

Me encontré con el mismo problema en el que necesitaba hacer algo como call('AFunction', 'foo', 'bar') en lugar de serializar/des-serializar cada interacción. Mi preferencia también era dejar la mayor parte del código en el servidor y simplemente usar el JavaScript para manejar la vista. WebSockets se ajustaba mejor debido a su apoyo natural para la comunicación bidireccional. Para simplificar el desarrollo de mi aplicación, construyo una capa sobre WebSockets para hacer llamadas de método remoto (como RPC).

He publicado el RMI/RPC biblioteca http://sourceforge.net/projects/rmiwebsocket/. Una vez que la comunicación se configura entre la página web y el servlet, puede ejecutar llamadas en cualquier dirección. El servidor usa la reflexión para llamar al método apropiado en el objeto del lado del servidor y el cliente usa el método 'Llamado' de JavaScript para llamar a la función apropiada en el objeto del lado del cliente. La biblioteca usa Jackson Cuidar la serialización/deserialización de varios tipos de Java hacia/desde JSON.

Answer 6

WebSocket JSR fue negociado por varias partes (Oracle, Apache, Eclipse, etc.), todas con agendas muy diferentes. Es igual que se detuvieron en el nivel de transporte de mensajes y dejaron construcciones de nivel superior. Si lo que necesita es un Java para JavaScript RMI, consulte el Marco de Fermi.