Why don't web sockets use SOAP?

Question

Firstly, I do not find any hostility and negligence, I just want to know the thoughts of people. I am considering bidirectional communication between client and server; the client is a web application. At the moment, I have several options: linking to the MS-branded duplex, from what I hear unreliable and unnatural: comet and web sockets (for supported browsers).

I know this question was asked in other ways, but I have a more specific question for this approach. Given that web sockets are client-side, the client code is in JavaScript. Is this the intention to create a large fragment of the application directly in JavaScript? Why didn't W3C do this in web services? Would it be easier if we could use SOAP to provide a contract and define events along with existing messaging? It just feels like the short end of a stick.

Why not make it simple and use the dynamic nature of JS and leave the bulk of the code where it belongs .... on the server?

Instead

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

we could say

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

and instead

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

we could say

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

HTML 5 lingered forever ... did we spend a lot of effort in the wrong direction? Thoughts?

Answer 1

It sounds like you haven’t fully understood the concepts around Websockets. For example, you say:

Given that web sockets are client

This is not so, sockets have two sides, you can think of it as a server and client, however, as soon as the connection is established, the difference is blurred - you can also think of the client and server as "peers" - everyone can write or read into the tube that connects them (socket connection) at any time. I suspect that it will be useful for you to learn a little more about how HTTP works over TCP. Thus, WebSockets is similar / similar to HTTP.

Regarding SOAP / WSDL, in terms of a TCP / WebSocket / HTTP conversation, you might think that all SOAP / WSDL conversations are identical to HTTP (i.e., normal web page traffic).

Finally, remember the complex network programming, for example, SOAP / WSDL looks like this:

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

And websockets look like this

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

NTN.

Answer 2

JavaScript allows clients to communicate over HTTP using XMLHttpRequest. WebSockets extends this functionality to allow JavaScript to do arbitrary network I / O (not just HTTP), which is a logical extension and allows all kinds of applications that need to use TCP traffic (but may not use HTTP) to use JavaScript . I think it’s pretty logical that as applications continue to move to the cloud, HTML and JavaScript support everything on the desktop.

Although the server can perform non-HTTP network I / O on behalf of the JavaScript client and makes this connection available through HTTP, this is not always the most appropriate or effective business. For example, it would be impractical to add additional costs back and forth when trying to make an online SSH terminal. WebSockets allows JavaScript to talk directly to the SSH server.

As for the syntax, part of it is based on XMLHttpRequest. As mentioned in another publication, WebSockets is a fairly low-level API that you can wrap more easily. It is more important that WebSockets supports all the necessary applications than the one that has the most elegant syntax (sometimes the emphasis on syntax can lead to more restrictive functionality). Library authors can always make this common API more manageable for other application developers.

Answer 3

As you noted, WebSockets have low overhead . The overhead is similar to regular TCP sockets: just two bytes per frame, compared to hundreds for AJAX / Comet.

Why a low-level, rather than some kind of built-in RPC function? Some thoughts:

• It's not that difficult to take the existing RPC protocol and run it on the low-level socket protocol. You cannot go in the opposite direction and build a low-level connection if RPC overhead is assumed.

• WebSockets support is pretty trivial to add to multiple languages ​​on the server side. The payload is just a UTF-8 string, and almost every language has built-in effective support for this. The RPC mechanism is not much. How do you handle data type conversions between Javascript and the target language? Need to add a hint type to the Javascript side? What about variable length arguments and / or argument lists? Do you build these mechanisms if the language does not have a good answer? Etc.

• What RPC mechanism will be modeled after? Would you choose an existing one (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) or a brand new one?

• Once client support is versatile enough, many services that have a regular TCP socket will add WebSockets support (because it's pretty trivial to add). The same is not true if WebSockets was based on RPC. Some existing services may add an RPC layer, but for the most part, WebSockets services will be created from scratch.

For my noVNC project (VNC client using only Javascript, Canvas, WebSockets), low priority WebSockets is critical to achieving reasonable performance. While VNC servers do not support WebSockets, noVNC includes wsproxy, which is the common WebSockets for a TCP proxy.

If you are thinking about implementing an interactive web application and you haven’t decided on a server language, I suggest looking at Socket.IO , which is the library for node (server-side Javascript using Google V8).

In addition to all the advantages of node (the same language on both sides, very efficient, powerful libraries, etc.), Socket.IO gives you several things:

• Provides a library of client and server frameworks for handling connections.

• Detects the best transport supported by both the client and server. Transports include (from best to worst): native WebSockets, WebSockets using Flash emulation, various AJAX models.

• A compatible interface no matter what transport is used.

• Automatic encoding / decoding of Javascript data types.

It is not possible to create an RPC mechanism on top of Socket.IO, since both sides are the same language with the same native types.

Answer 4

WebSocket makes the comet and all other methods such as HTTP-push legible, allowing requests to be launched from the server. It is a kind of sandbox and gives us limited functionality.

However, the API is general enough for developers of frameworks and libraries to improve the interface depending on what they want. For example, you can write a RPC or RMI service in the WebSockets style, which allows you to send objects by cable. Now internally they are serialized in some unknown format, but the user of the service does not need to know and does not care.

So, thinking from POV authors, moving from

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

to

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

It is relatively easy and requires writing a small wrapper around WebSockets so that serialization and deserialization are opaque to the application. But moving in the opposite direction means that the authors of the performance need to make a much more complex API, which makes the foundation for writing code on top of it weaker.

Answer 5

I ran into the same problem when I needed to do something like call('AFunction', 'foo', 'bar') and not serialize / de-serialize each interaction. My preference was also to leave the bulk of the code on the server and just use Javascript to process the view. WebSockets were better suited because of its natural support for bi-directional communication. To simplify the development of my application, I create a layer on top of WebSockets to make remote method calls (like RPC ).

I published the RMI/RPC library at http://sourceforge.net/projects/rmiwebsocket/ . Once the connection between the web page and the servlet is established, you can make calls in any direction. The server uses reflection to invoke the corresponding method on the server object, and the client uses the Javascript call method to invoke the corresponding function on the client object. The library uses Jackson to take care of serializing / deserializing various types of Java to / from JSON.

Answer 6

WebSocket JSR has been agreed by a number of parties (Oracle, Apache, Eclipse, etc.) with very different tasks. They also stopped at the level of message transport and left structures of a higher level. If you need Java-JavaScript RMI, check out the FERMI Framework .