代码之家 › 专栏 › 技术社区 › Benny

为什么网络插座使用SOAP?

websocket html5 soap

Benny · 技术社区 · 14 年前

首先,我不想有任何敌意或否定,只想知道人们的想法。我正在研究客户机和服务器之间的双向通信;客户机是一个Web应用程序。现在,我有几个选项:MS专有的双工绑定,从我听到的不可靠和不自然的内容来看:Comet和Web套接字(对于受支持的浏览器)。

我知道这个问题在这里是以其他方式被问到的,但是我对这个方法有一个更具体的问题。考虑到Web套接字是客户端的,客户端代码位于javascript中。是否真的打算直接用JavaScript构建一个大的应用程序块?为什么W3C没有在Web服务中这样做?如果我们能够使用SOAP来提供一个契约,定义事件以及所涉及的现有消息传递,这难道不是更容易吗?到目前为止感觉就像是短棍。

为什么不让它变得简单,利用JS的动态特性,把它所属的大部分代码留在服务器上呢?

而不是

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

我们可以说

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

而不是

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

我们可以说

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

HTML 5花了很长时间才获得成功……我们是否在错误的方向上浪费了大量的精力?思想?

6 回复 | 直到 11 年前

Robin 14 年前

在我看来,你还没有完全理解WebSockets的概念。例如,你说:

考虑到Web套接字是客户端的

但情况并非如此,套接字有两个方面,您可以将它们视为服务器和客户机,但是一旦建立了连接,区别就变模糊了—您也可以将客户机和服务器视为“对等机”—每个都可以在任何时候写入或读取连接它们的管道(套接字连接)。我怀疑在TCP之上学习更多关于HTTP工作的知识会使您受益匪浅——WebSockets以这种方式类似于/类似于HTTP。

对于soap/wsdl,从围绕tcp/websocket/http的会话的角度来看,您可以将所有soap/wsdl会话视为与http相同(即正常的网页流量)。

最后,请记住网络编程的堆叠性质,例如SOAP/WSDL如下所示:

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

WebSockets看起来像这样

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

Hth.

Michael Aaron Safyan 14 年前

javascript允许客户机通过HTTP与xmlhttprequest进行通信。WebSockets扩展了此功能,允许javascript进行任意网络I/O(不仅仅是HTTP),这是一个逻辑扩展,允许将需要使用TCP通信(但可能不使用HTTP协议)的各种应用程序移植到javascript。我认为,当应用程序继续向云端移动时,HTML和JavaScript支持桌面上所有可用的东西,这是相当合乎逻辑的。

虽然服务器可以代表JavaScript客户机执行非HTTP网络I/O,并使通过HTTP的通信可用,但这并不总是最合适或最有效的事情。例如,在尝试创建在线ssh终端时,增加额外的往返成本是没有意义的。WebSockets使JavaScript可以直接与ssh服务器通信。

至于语法,它的一部分基于xmlhttprequest。正如另一篇文章所指出的,WebSockets是一个相当低级的API,可以用一个更易于理解的API进行包装。WebSockets支持所有必要的应用程序比它拥有最优雅的语法更重要(有时关注语法会导致更严格的功能)。库作者总是可以让其他应用程序开发人员更容易管理这个非常通用的API。

kanaka 14 年前

正如你所指出的,websockets 低开销 . 开销类似于普通的TCP套接字:每帧只比Ajax/Comet多两个字节。

为什么是低级的而不是某种内置的RPC功能?一些想法:

采用现有的RPC协议并不难,而且层它在低级套接字协议上。如果假设有RPC开销,则不能反向构建低级连接。
WebSockets支持是 相当琐碎 添加到服务器端的多种语言。有效负载只是一个utf-8字符串,几乎每种语言都有内置的有效支持。一个RPC机制就不那么多了。如何处理JavaScript和目标语言之间的数据类型转换?是否需要在javascript端添加类型提示?变长参数和/或参数列表呢?如果语言没有很好的答案,您是否建立了这些机制?等。
它将以哪个RPC机制为模型?您会选择现有的(SOAP、XML- RPC、JSON-RPC、Java RMI、AMF、RPYC、CORBA)还是全新的?
一旦客户机支持是相当普遍的,那么许多具有普通TCP套接字的服务将添加WebSockets支持(因为添加它相当简单)。如果WebSockets是基于RPC的,则情况也不一样。一些现有的服务可能会添加一个RPC层,但对于大多数情况下,WebSockets服务将从头开始创建。

为了我 noVNC Project(VNC客户端仅使用javascript、canvas、websockets)websockets的低开销特性对于实现合理的性能至关重要。在VNC服务器包含WebSockets支持之前,NOVNC包含wsproxy,它是TCP套接字代理的通用WebSockets。

如果您正在考虑实现交互式Web应用程序,但还没有决定使用服务器端语言,那么我建议您查看 Socket.IO 哪个是图书馆 node (使用Google的V8引擎的服务器端javascript)。

除了node的所有优点(两边的语言相同、效率很高、电源库等),socket.io还提供了以下几点:

为处理连接提供客户端和服务器框架库。
检测客户端和服务器都支持的最佳传输。传输包括(从最好到最坏):本机WebSocket、使用Flash仿真的WebSocket、各种Ajax模型。
不管使用什么传输,都保持一致的接口。
自动编码/解码javascript数据类型。

在socket.io上创建一个RPC机制并不难,因为两边都是相同语言,具有相同的本地类型。

Anurag 14 年前

WebSocket允许来自服务器的请求,从而使Comet和所有其他HTTP推送类型技术清晰易读。它是一种沙盒插座,功能有限。

然而,对于框架和库作者来说,API已经足够通用,可以以他们想要的任何方式改进接口。例如,您可以在WebSockets上编写一些rpc或rmi样式的服务,允许通过网络发送对象。现在在内部,它们以某种未知的格式被序列化,但是服务用户不需要知道也不关心。

所以从规范作者的角度思考,从

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

到

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

相对容易,需要在WebSockets周围编写一个小包装器,以便序列化和反序列化对应用程序产生不利影响。但是,相反的方向意味着规范作者需要做一个更复杂的API,这使得在上面写代码的基础较弱。

Wilk Bodhisatwa Ghosh 12 年前

我遇到了同样的问题,我需要做些什么 call('AFunction', 'foo', 'bar') 而不是序列化/反序列化每个交互。我的偏好是把大部分代码留在服务器上,只使用javascript来处理视图。WebSockets由于其对双向通信的自然支持而更加适合。为了简化我的应用程序开发,我在WebSockets上构建了一个层来进行远程方法调用(比如 RPC )

我已经发表了 RMI/RPC 图书馆 http://sourceforge.net/projects/rmiwebsocket/ . 一旦在网页和servlet之间建立了通信,就可以在任意方向上执行调用。服务器使用反射调用服务器端对象中的相应方法,客户端使用javascript的“call”方法调用客户端对象中的相应函数。图书馆使用 Jackson 注意从JSON到JAVA的各种Java类型的序列化/反序列化。

Forelight 11 年前

websocket jsr由多个各方(Oracle、Apache、Eclipse等)协商,所有各方的议程都非常不同。同样,它们在消息传输级别停止,并将更高级别的构造留在外面。如果您需要的是Java到JavaScript RMI,请检查 FERMI Framework .