Inside every computer, every time you click a key or the mouse, thousands of “procedure calls” are spawned, analyzing, computing and then acting on your gestures.
For example, when you move your mouse over an icon, the computer calls a procedure, LocateMouse, to figure out what you’re pointing at.
Is the mouse pointing at a menu? At a scroll bar? If so, which part of the scroll bar? Is it pointing at an icon? Or some text? Every possibility is considered.
OK, so let’s say the mouse is pointing at an icon when you click the mouse button. What kind of icon is it? If it’s a printer, call the procedure that prints things. What do you do when the user clicks the mouse on this kind of icon? A special procedure answers that question.
This is the kind of chatter that’s going on inside your computer *all the time*, even when you aren’t there. It’s always asking questions. And the answers come from procedures. To get an answer, the software “calls” the procedure.
Parameters and returned values
Along with the call, the procedure might require some extra information, so it doesn’t have to recompute things that other procedures might have already figured out. These are called “parameters”.
The LocateMouse procedure might need to be told where the mouse is. The location of the mouse is usually expressed in a coordinate system like the Cartesian plane that you learned about in high school. An x coordinate and a y coordinate. Such a procedure would be said to “take” two parameters, an x and a y.
Parameters are important for three reasons. First, why do the work again when the caller probably already knows where the mouse is? And second, the mouse may have moved in the time it took to call the LocateMouse procedure. And third, a procedure may be called to do some computation, for example, to look up a record in a database. Such a procedure would require a user’s name or account number as a parameter, to identify the record that’s to be looked up.
And there’s the motivation for the third part of a procedure call — the returned value. It’s the answer that the procedure sends back to the procedure that called it. A database-access procedure call might return a set of values, all the elements of the record indicated by the key identifier it received as a parameter.
What is a procedure call?
So, now we’re ready to say, concisely, what a procedure call is.
A procedure call is the name of a procedure, its parameters, and the result it returns.
Why are procedure calls important? A very simple answer. Without them, there would be no computers!
Every program is just a single procedure called main, every operating system has a main procedure called a kernel. There’s a top level to every program that sits in a loop waiting for something to happen and then distributes control to a hierarchy of procedures that respond. This is at the heart of interactivity and networking, it’s at the heart of software.
What is RPC?
RPC is a very simple extension to the procedure call idea, it says let’s create connections between procedures that are running in different applications, or on different machines.
Conceptually, there’s no difference between a local procedure call and a remote one, but they are implemented differently, perform differently (RPC is much slower) and therefore are used for different things.
Remote calls are “marshalled” into a format that can be understood on the other side of the connection. As long as two machines agree on a format, they can talk to each other. That’s why Windows machines can be networked with other Windows machines, and Macs can talk to Macs, etc. The value in a standardized cross-platform approach for RPC is that it allows Unix machines to talk to Windows machines and vice versa.
What is XML-RPC?
There are an almost infinite number of formats possible. One possible format is XML, a new language that both humans and computers can read. XML-RPC uses XML as the marshalling format. It allows Macs to easily make procedure calls to software running on Windows machines and BeOS machines, as well as all flavors of Unix and Java, and IBM mainframes, and PDAs and sewing machines (they have computers in them too these days).
With XML it’s easy to see what it’s doing, and it’s also relatively easy to marshall the internal procedure call format into a remote format.
Why RPC is important
OK, now that we understand what XML-RPC is, let the XML part fade into the background. It’s an implementation detail. Programmers are interested in XML, as are web developers, but if you’re a user or an investor, XML is about as important as C++ or Java. The developers like it, or seem to, and that’s the only major take-away from the XML part of XML-RPC.
But RPC is important, no matter what format is used, because it allows choices, you can replace a component with another one; and it opens possibilities, empowering advanced users to develop solutions with packaged software that the developers didn’t anticipate.