Por que os soquetes da web não usam sabão?

Question

Primeiro, não pretendo hostilidade nem neglegence, apenas quero conhecer os pensamentos das pessoas. Estou analisando a comunicação bidirecional entre cliente e servidor; cliente sendo um aplicativo da web. Neste ponto, tenho algumas opções: encadernação duplex do MS-Proprietário, pelo que ouço não confiável e não natural: cometa e soquetes da web (para navegadores suportados).

Sei que essa pergunta foi feita de outras maneiras aqui, mas tenho uma pergunta mais específica para a abordagem. Considerando que os soquetes da Web são do lado do cliente, o código do cliente fica no JavaScript. É realmente a intenção de construir uma grande parte de um aplicativo diretamente no JavaScript? Por que o W3C não fez isso nos serviços da web? Não seria mais fácil se pudéssemos usar sabão para fornecer um contrato e definir eventos junto com as mensagens existentes envolvidas? Parece o final curto do bastão até agora.

Por que não simplificar e aproveitar a natureza dinâmica do JS e deixar a maior parte do código onde ele pertence .... no servidor?

Ao invés de

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

Poderíamos dizer

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

e em vez de

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

Poderíamos dizer

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

O HTML 5 levou uma eternidade para se aposentar .... desperdiçamos uma grande quantidade de esforço na direção errada? Pensamentos?

Answer 1

Parece -me que você ainda não entendeu completamente os conceitos em torno da WebSockets. Por exemplo, você diz:

Considerando os soquetes da web são do lado do cliente

Não é esse o caso, os soquetes têm 2 lados, você pode pensar neles como um servidor e um cliente, no entanto, uma vez que a conexão seja estabelecida, a distinção se obscurece - você também pode pensar no cliente e no servidor como "pares" - cada um pode escrever ou ler no tubo que os conecta (a conexão do soquete) a qualquer momento. Suspeito que você se beneficie de aprender um pouco mais sobre o HTTP Works em cima do TCP - o WebSockets é semelhante / análogo ao HTTP dessa maneira.

Em relação ao SOAP / WSDL, do ponto de vista de uma conversa em torno do TCP / WebSocket / HTTP, você pode pensar em todas as conversas SOAP / WSDL como idênticas ao HTTP (ou seja, tráfego normal da página da web).

Por fim, lembre -se da natureza empilhada da programação de rede, por exemplo, SOAP/WSDL se parece com o seguinte:

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

E websockets se parecem com isso

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

Hth.

Answer 2

O JavaScript permite que os clientes se comuniquem via HTTP com o XMLHTTPREQUEST. Os websockets estendem essa funcionalidade para permitir que o JavaScript faça E/S de rede arbitrária (não apenas HTTP), que é uma extensão lógica e permite que todos os tipos de aplicativos que precisam usar o tráfego TCP (mas podem não estar usando o protocolo HTTP) para ser portada para JavaScript. Eu acho que é bastante lógico que, à medida que os aplicativos continuam a se mudar para a nuvem, o HTML e o JavaScript suportam tudo o que está disponível na área de trabalho.

Embora um servidor possa fazer E/S de rede não HTTP em nome de um cliente JavaScript e disponibilizar essa comunicação sobre o HTTP, essa nem sempre é a coisa mais apropriada ou eficiente a fazer. Por exemplo, não faria sentido adicionar um custo adicional de ida e volta ao tentar fazer um terminal SSH online. O WebSockets possibilita que o JavaScript converse diretamente com o servidor SSH.

Quanto à sintaxe, parte dele é baseada no XMLHTTPREQUEST. Como foi apontado na outra postagem, o WebSockets é uma API de nível bastante baixo que pode ser embrulhada em uma mais compreensível. É mais importante que os WebSockets suportem todos os aplicativos necessários do que a sintaxe mais elegante (às vezes focando na sintaxe pode levar a uma funcionalidade mais restritiva). Os autores da biblioteca sempre podem tornar essa API muito geral mais gerenciável para outros desenvolvedores de aplicativos.

Answer 3

Como você observou Websockets tem baixa sobrecarga. A sobrecarga é semelhante aos soquetes normais do TCP: apenas dois bytes mais por quadro em comparação com centenas para Ajax/Cometa.

Por que baixo nível em vez de algum tipo de funcionalidade RPC integrada? Alguns pensamentos:

• Não é tão difícil tomar um protocolo RPC existente e camada em um protocolo de soquete de baixo nível. Você não pode seguir a direção oposta e criar uma conexão de baixo nível se a sobrecarga do RPC for assumida.

• O suporte WebSockets é razoavelmente trivial Para adicionar a vários idiomas no lado do servidor. A carga útil é apenas uma string UTF-8 e praticamente todos os idiomas têm suporte eficiente interno para isso. Um mecanismo de RPC não tanto. Como você lida com conversões de tipo de dados entre JavaScript e o idioma de destino? Você precisa adicionar o tipo de sugestão do lado JavaScript? E os argumentos de comprimento variável e/ou listas de argumentos? Você constrói esses mecanismos se o idioma não tiver uma boa resposta? Etc.

• Qual mecanismo de RPC seria modelado depois? Você escolheria um existente (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPYC, CORBA) ou um totalmente novo?

• Depois que o suporte ao cliente for bastante universal, muitos serviços que possuem soquete TCP normal adicionarão suporte do WebSockets (porque é bastante trivial adicionar). O mesmo não é verdadeiro se o WebSockets foi baseado em RPC. Alguns serviços existentes podem adicionar uma camada RPC, mas, na maioria das vezes, os serviços da WebSockets serão criados do zero.

Para o meu Novnc Projeto (cliente VNC usando Just JavaScript, Canvas, Websockets) A natureza de baixa cabeça dos Websockets é fundamental para alcançar um desempenho razoável. Até que os servidores VNC incluam suporte WebSockets, o NOVNC inclui o WSProxy, que é um proxy genérico do WebSockets para TCP.

Se você está pensando em implementar um aplicativo interativo da Web e não decidiu no idioma do lado do servidor, sugiro olhar Socket.io que é uma biblioteca para nó (JavaScript do lado do servidor usando o mecanismo V8 do Google).

Além de todas as vantagens do nó (o mesmo idioma de ambos os lados, bibliotecas de energia muito eficientes, etc.), o Socket.io oferece várias coisas:

• Fornece biblioteca de estruturas de clientes e servidores para lidar com conexões.

• Detecta o melhor transporte suportado pelo cliente e pelo servidor. Os transportes incluem (do melhor para o pior): WebSockets nativos, WebSockets usando emulação flash, vários modelos Ajax.

• Interface consistente, independentemente do transporte usado.

• Encodes/decodificação automática de dados de dados JavaScript.

Não seria tão difícil criar um mecanismo RPC no topo do soquete.io, pois ambos os lados são o mesmo idioma com os mesmos tipos nativos.

Answer 4

O WebSocket torna legível o Cometa e todas as outras técnicas de tipo HTTP, permitindo que as solicitações sejam originárias do servidor. É uma espécie de soquete de caixa de areia e nos dá funcionalidade limitada.

No entanto, a API é geral o suficiente para que os autores da estrutura e da biblioteca melhorem a interface da maneira que desejarem. Por exemplo, você pode escrever algum serviço com estilo RPC ou RMI em cima do WebSockets que permitem enviar objetos sobre o fio. Agora, internamente, eles estão sendo serializados em algum formato desconhecido, mas o usuário do serviço não precisa saber e não se importa.

Então, pensando em um POV de autores de especificações, indo de

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

para

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

é comparativamente fácil e requer escrever uma pequena embalagem em torno da WebSockets, para que a serialização e a desserialização aconteçam opacetamente ao aplicativo. Mas ir na direção inversa significa que os autores de especificações precisam criar uma API muito mais complexa, o que contribui para uma base mais fraca para escrever código sobre ela.

Answer 5

Eu encontrei o mesmo problema em que precisava fazer algo como call('AFunction', 'foo', 'bar') em vez de serializar/despersar todas as interações. Minha preferência também foi deixar a maior parte do código no servidor e apenas usar o JavaScript para lidar com a visualização. A WebSockets foi mais adequada devido ao seu apoio natural à comunicação bidirecional. Para simplificar o desenvolvimento do meu aplicativo, construo uma camada em cima do WebSockets para fazer chamadas de método remoto (como RPC).

Eu publiquei o RMI/RPC biblioteca em http://sourceforge.net/projects/rmiwebsocket/. Depois que a comunicação é configurada entre a página da web e o servlet, você pode executar chamadas em qualquer direção. O servidor usa a reflexão para chamar o método apropriado no objeto do lado do servidor e o cliente usa o método 'chamado' do JavaScript para chamar a função apropriada no objeto do lado do cliente. A biblioteca usa Jackson cuidar da serialização/deserialização de vários tipos de Java de/para JSON.

Answer 6

O WebSocket JSR foi negociado por várias partes (Oracle, Apache, Eclipse, etc), tudo com agendas muito diferentes. É tão bom que eles pararam no nível de transporte de mensagens e deixaram construções de nível mais alto. Se o que você precisa é um java para javascript rmi, confira o Estrutura de Fermi.