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 |