Web (JavaScript) Remote Call solution list

Web Remote Process calling (webrpc) is a recent hot topic for calling remote methods without refreshing new pages. In some cases, he even becomes an irreplaceable implementation method. The implementation of webrpc has gone through reading from common URLs, hiding frames, IFRAME, XMLHTTP, and even flash. This article will list existing webrpc solutions (products) and make a simple evaluation.

The evaluation will be carried out in the following aspects: client implementation, server implementation, self-encapsulated protocol, serialization/deserialization supported, and serialization supported (atomic type, object type), whether the asynchronous/Synchronous mode is supported. Note that web-based remote calls are not widely used. I have no experience using webrpc in enterprise applications, but it has been well applied in entertainment applications and online games. These applications have been elaborated in amowa. If you are interested, read this article in the Product Guide.Article.

1 MSRs (Microsoft Remote scripting)

Http://msdn.microsoft.com/library/default.asp? Url =/library/en-US/rmscpt/html/rmscpt1.asp

Introduction: In the early days of Web Page appearance, browser functions were limited. The emergence of Applet provides a platform for MSRs. In this solution, MSRs interacts with the server through an applet class and parameter configuration on the page, thus achieving remote calls. Using this technology, we actually handed over the non-Refresh page to an invisible applet named rsproxy. Class. I have seen early online web chess adopt this solution. Advantages: easy cross-browser; disadvantages: Microsoft ASP is used on the server, and Applet loading is slow; Data Type serialization/deserialization is not supported.

2 jsrs (JavaScript remote scripting)

Address: http://www.blueshoes.org/en/javascript/jsrs/

Introduction: two data access methods are supported: http get (dynamic loading of JS files) and http post (using js to dynamically create an IFRAME and submit a form ). You do not need to refresh the page and support serialization/deserialization of simple data.

3 XML-RPC

Address: http://www.xmlrpc.org/

Introduction: XML-RPC defines a protocol specification, because of its lightweight, complete concept, so the vast majority of languages are currently implemented, including Java (apache xml-RPC), PHP, JavaScript, VBScript, Python, and so on. The largest way to communicate blog protocol, management methods also follow the XML-RPC specifications. Advantage: Most languages are supported, simple, and standard. Disadvantage: Java provides limited support for data type serialization.

4 DWR (Direct Web remoting)

Address: https://dwr.dev.java.net/

Introduction: a small thing that puts forward appropriate concepts when appropriate. XMLHTTP is used to send requests. The server uses reflection to find the corresponding method and then returns the result. It is more creative that he needs to remotely call the serverCodeDynamically convert to the corresponding JS Code, and the front-end can be called explicitly. It is simple and can be used as an entry to webrpc learning. Data serialization is not supported.

JSON-RPC

Address: http://oss.metaparadigm.com/jsonrpc/

Introduction: using a kind of never heard of the Data Exchange Protocol JSON (JavaScript Object Notation, http://www.crockford.com/JSON/) as the Protocol basis, on which data calls, using XMLHTTP to send/accept requests, supports complete data serialization/deserialization. Currently, the Jason Web framework uses JSON-RPC as the underlying mode.

6 burlap (http://caucho.com/burlap/index.xtp)

Summary: It may be strange why burlap can be considered as a remote protocol. In fact, burlap, which is basically the same as Hessian implementation method (the former is binary and the latter is text), can surpass any of the above products in terms of protocol integrity. Currently, I have implemented code for js to call the burlap service, which is the most elegant implementation in all remote call methods.

7 Xins (XML interface for Network Services)

Address: http://xins.sourceforge.net/index.html

Introduction: according to the official website, soa + Java + XML + code_generation-complexity => Xins. This huge object requires defining a package of description files before it can be called in HTML. In terms of appearance, this is the most similar solution. I don't know much about it, so I don't comment on it.

8. WebService and soap

Introduction: Apart from Microsoft's WebService. HTC control, Mozilla also has a corresponding WebService access method. Therefore, it is also feasible to access WebService in HTML. This Protocol is too cumbersome, unless necessary, and no one will use it on the Web Client.

	Client implementation	Server implementation	Self-encapsulated protocol?	Serialization/deserialization	Synchronous mode/asynchronous mode
MSRs	Applet	Microsoft ASP	None	Not Supported	Synchronous + asynchronous
Jsrs	IFRAME/dynamic loading JS	Various, PHP, Java, etc.	None	Not Supported	Synchronization
XML-RPC	XMLHTTP and other methods	Most languages are supported	XML-RPC	Supported. Java implementation is limited. Custom objects are not supported.	Synchronous + asynchronous
DWR	XMLHTTP	Java	None	Weak	Synchronous + asynchronous
JSON-RPC	XMLHTTP	Java	JSON	Supported	Synchronous + asynchronous
Burlap	XMLHTTP	Java	Burlap	Fully supported	Synchronous + asynchronous
Xins	XMLHTTP	Java	Yes	Supported	Synchronous + asynchronous
WebService	IE adopts. HTC and Mozilla built-in support	Not always. Follow the WebService specifications and the SOAP protocol.	Soap	Supported. different platforms have extensions.	Synchronous + asynchronous