RemoteProcedureCalls
From MorphixWiki
bascavarri racern darelttado bocololar getvirocasit racallet
HomePage
Just one of those lists that I've been wanting to write. There are a lot of various ways to call functions on other computers, and if you call them web services, RPC or gobblygook, they all have the same goal: get another computer to do stuff for you. I decided to write up this list after getting half-way through a network programming course and having done quite a few webservice implementations for both work and university courses. You may disagree with me.
Sun RPC
The granddaddy of RPC, available on many/all Unix-like systems. Using Sun RPC, you can send and receive any kind of datastructure using a function on a remote server. NFS uses RPC, as do many 'older' (and inherently insecure) networking tools like rcp, rlogin and rsh.
In short, you define the functions and input/output variables in a .x file, after which you use rpcgen to generate stubs for both your server and client (ending up in Xclnt.c, Xsvc.c and X_xdr.c files). The big deal with Sun RPC is the fact that it looks like you're using pointers on the server side and the same data is available on the client side. Needlessly to point out, this makes Sun RPC rather complicated to write from scratch, which rpcgen was made for. Even so, it's a blazing-fast way of calling remote functions in C, and bindings are available for nearly any language.
For more info, see [1]
Sun / Java RMI
Evolved from Sun RPC as a way of calling remote objects in Java, RMI is in Object Oriented Programming land what RPC is for C.
XML-RPC
With the whole XML-hype, it didn't take long or people wanted to call functions in XML. Personally I find it rather useless when you can do the same without having to convert to-from XML, however XML-RPC is one of the easiest ways of using RPC and is one of the more simpler combinations of RPC and XML (in contrast with SOAP). With implementations in C/C++, Java, PHP, Perl, Python and .Net, XML-RPC is well-supported and used in many production applications.
I have personally used usefulinc's XML-RPC implementation for PHP4 frequently, and it works as advertised.
For more info, see [2]], [[3]], [[4]] and [[5].
SOAP / WSDL
The juggernaut combining XML and RPC, SOAP and it's description language WSDL are relatively heavy. Requiring lots of parsing and huge transmission sizes, it's easy to see it was made by a committee and not by a sane developer.
One of the interesting things of WSDL is that you can generate client-side code using it. This makes it incredibly easy to get up and running with a client against a webservice.
I have personally used SOAP together with Apache Axis and NuSOAP, and prefer the latter due to it's simplicity.
For more info, see [6]], [[7]], http://ws.apache.org/axis/. [[8] is nice for Perl mongers (which also supports XML-RPC).
CORBA
A beast and another result of a committee (aptly named OMG). Built to send around objects between incompatible applications, CORBA likes to call itself Middleware, which can be translated to "glue for heaps of stuff that don't work together and we don't want to dig into the code too much". It is very similar to Java RMI but language-independant.
The Gnome developers were totally CORBA-addicts at a certain point (I still haven't figured out why), with their implementation called Bonobo they were able to send widgets and windows over the network. It never really took off as things were much too complicated and unwieldy, they're now much more into local message passing through less complicated stuff like dbus and HAL.
In my book, if you need 400+ pages to specify how your RPC standard works there's only one solution: burn it all and start over again.
For more info, see [9].
Ajax, or Asyncronous Javascript and XML, or just simply using XMLHttpRequest
After Google Suggest came out with an autocompletion interface this technology was shoved out into the spotlight. It has in fact existed for quite a few years now, no matter how you call it it still is a useful addition for anyone having to deal with dynamic webpages. In short, requests are packed up using client-side Javascript as XML, which is sent to a server. The server sends back an XML-ized reply, without having to block the client at all (as such, the request is asyncronous).
Relatively new, this technique tends to only work well with Mozilla/Firefox and IE6+. It's not directly comparable to XML-RPC or SOAP, as these two are ways of packing requests in XML, with Ajax this is left to the implementer to decide. However, toolkits like Sajax and JPSpan are available that generate stubs and greatly ease the usage of XMLHttpRequests.
For more info, see [10]] and [[11]
DCOM, COM, XPCOM and the like
TODO
