2010-10-24 19 views
7

En primer lugar, no pretendo hostilidad ni negguencia, solo quiero conocer los pensamientos de las personas. Estoy buscando una comunicación bidireccional entre el cliente y el servidor; el cliente es una aplicación web. En este punto, tengo algunas opciones: enlace dúplex propiedad de MS, por lo que escucho poco confiable y antinatural: cometa y sockets web (para navegadores compatibles).¿Por qué Web Sockets no usa SOAP?

Sé que esta pregunta se ha planteado de otras maneras aquí, pero tengo una pregunta más específica al respecto. Considerando que los sockets web están en el lado del cliente, el código del cliente se encuentra en JavaScript. ¿Realmente es la intención crear una gran parte de una aplicación directamente en JavaScript? ¿Por qué el 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 la mensajería existente involucrada? Solo se siente como el extremo corto del palo hasta el momento.

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

En lugar 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 demoró para siempre ... ¿Perdimos una gran cantidad de esfuerzo en la dirección incorrecta? ¿Pensamientos?

Respuesta

18

Me parece que aún no ha entendido por completo los conceptos de Websockets. Por ejemplo, usted decir:

Teniendo en cuenta los zócalos web son del lado del cliente

Este no es el caso, enchufes tienen 2 lados, se puede pensar en ellos como un servidor y un cliente, sin embargo una vez que el se establece la conexión, la distinción se difumina; también podría pensar en el cliente y el servidor como "pares"; cada uno puede escribir o leer en el conducto que los conecta (la conexión del zócalo) en cualquier momento. Sospecho que te beneficiarías si aprendieras un poco más sobre el funcionamiento de HTTP sobre TCP: WebSockets es similar/análogo al HTTP de esta manera.

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

Por último, recordar la naturaleza apilada de programación de la red, por ejemplo SOAP/WSDL se ve así:

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

Y WebSockets este aspecto

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

HTH.

+0

¿por qué se bajó este voto? – Anurag

+5

Bueno, la parte de apilamiento no es del todo cierto. Aunque, en la mayoría de los casos, SOAP se envía a través de HTTP, WSDL permite definir enlaces arbitrarios. Como WSDL es muy extensible por diseño, es posible definir e implementar un enlace SOAP sobre Websockets. De esta forma sería SOAP -> Websocket -> TCP, donde SOAP es solo el formato de codificación del mensaje. Incluso en el ejemplo esbozado en esta respuesta, los datos que se envían a través del websocket se codifican de alguna manera, p. como JSON. Entonces, la analogía correcta sería JSON -> Websocket -> TCP vs. SOAP -> Websocket -> TCP vs. SOAP -> HTTP -> TCP. – vanto

+0

@vanto ¿Existe algún estándar de codificación JSON para "JSON en WebSocket en TCP"? ¿Algo similar a lo que hizo SOAP con XML? –

1

WebSocket hace que Comet y todas las demás técnicas de tipo de inserción HTTP sean legibles al permitir que las solicitudes se originen en el servidor. Es una especie de socket de espacio aislado y nos da una funcionalidad limitada.

Sin embargo, la API es lo suficientemente general para que los autores del framework y de la biblioteca mejoren la interfaz de la forma que deseen. Por ejemplo, podría escribir algún servicio de estilo RPC o RMI sobre WebSockets que permita enviar objetos por cable. Ahora internamente están siendo serializados en un formato desconocido, pero el usuario del servicio no necesita saber y no le importa.

Así que pensar desde autores de especificaciones POV, al pasar de

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

a

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

es relativamente fácil y no requiere escribir un pequeño envoltorio alrededor de WebSockets para que la serialización y deserialización sucede opaca a la aplicación . Pero ir en la dirección contraria significa que los autores de la especificación necesitan crear una API mucho más compleja que crea una base más débil para escribir código sobre ella.

3

JavaScript permite a los clientes comunicarse a través de HTTP con XMLHttpRequest. WebSockets amplía esta funcionalidad para permitir que JavaScript haga E/S de red arbitrarias (no solo HTTP), que es una extensión lógica y permite todo tipo de aplicaciones que necesitan usar el tráfico TCP (pero pueden no estar usando el protocolo HTTP) para ser portado a JavaScript Creo que es bastante lógico que, a medida que las aplicaciones continúen moviéndose a la nube, ese HTML y JavaScript admitan todo lo que está disponible en el escritorio.

Si bien un servidor puede realizar 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 permite que JavaScript hable directamente al 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 puede ser envuelta en una más comprensible. Es más importante que WebSockets soporte todas las aplicaciones necesarias que la que tiene la sintaxis más elegante (a veces enfocarse en la sintaxis puede llevar a una funcionalidad más restrictiva). Los autores de la biblioteca siempre pueden hacer que esta API general sea más manejable para otros desarrolladores de aplicaciones.

+0

No se puede conectar directamente a un socket sin formato usando WebSockets (hay un saludo de mano y dos bytes de encuadre). Mi proyecto noVNC incluye 'wsproxy' (http://github.com/kanaka/noVNC/tree/master/utils/) que proxies entre WebSockets y sockets TCP sin formato. – kanaka

3

Como se indicó, WebSockets tiene bajo costo. La sobrecarga es similar a los sockets TCP normales: solo dos bytes más por cuadro en comparación con cientos para AJAX/Comet.

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

  • No es tan difícil de tomar un protocolo RPC existente y capa que en un protocolo de toma de bajo nivel. No puede ir en la dirección opuesta y construir una conexión de bajo nivel si se supone que la sobrecarga de 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 de RPC no tanto. ¿Cómo se manejan las conversiones de tipos de datos entre Javascript y el idioma de destino? ¿Necesita agregar sugerencia de tipo en el lado de Javascript? ¿Qué pasa con los argumentos de longitud variable y/o las listas de argumentos? ¿Construyes estos mecanismos si el idioma no tiene una buena respuesta? Etc.

  • ¿Con qué mecanismo RPC se modelizaría? ¿Elegirías uno existente (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) o uno completamente nuevo?

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

Por mi noVNC proyecto (cliente VNC usando sólo JavaScript, lienzo, WebSockets) la naturaleza de baja sobrecarga de WebSockets es fundamental para lograr un rendimiento razonable. Hasta que los servidores VNC incluyan la compatibilidad con WebSockets, noVNC incluye wsproxy, que es un proxy de socket WebSockets genérico a TCP.

Si usted está pensando en implementar una aplicación web interactiva y no se ha decidido sobre lenguaje de servidor, entonces le sugiero mirando Socket.IO que es una biblioteca para node (del lado del servidor usando Javascript motor V8 de Google).

Además de todas las ventajas del nodo (el mismo idioma en ambos lados, muy eficiente, bibliotecas de alimentación, etc.), Socket.IO le ofrece varias cosas:

  • Proporciona una biblioteca de marco de cliente y servidor para manejar las conexiones.

  • Detecta el mejor transporte admitido tanto por el cliente como por el servidor. Los transportes incluyen (de mejor a peor): WebSockets nativos, WebSockets usando emulación de flash, varios modelos de AJAX.

  • Interfaz uniforme sin importar el tipo de transporte utilizado.

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

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

0

Me encontré con el mismo problema donde tenía que hacer algo como call('AFunction', 'foo', 'bar') en lugar de serializar/de-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. Los WebSockets encajan mejor debido a su soporte natural para la comunicación bidireccional. Para simplificar el desarrollo de mi aplicación, construyo una capa sobre WebSockets para hacer llamadas a métodos remotos (como RPC).

He publicado la biblioteca RMI/RPC en 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 de "llamada" de Javascript para llamar a la función apropiada en el objeto del lado del cliente. La biblioteca usa Jackson para encargarse de la serialización/deserialización de varios tipos de Java a/desde JSON.

0

WebSocket JSR fue negociado por una serie de partes (Oracle, Apache, Eclipse, etc.), todas con agendas muy diferentes.Es igual de bien que se detuvieron en el nivel de transporte de mensajes y dejaron construcciones de nivel superior. Si lo que necesita es una RMI de Java a JavaScript, consulte el FERMI Framework.