Defending Something Other Than RPC
Josh Haberman takes me to task for my previous posting:
Steve Vinoski has come out very vocally against RPC in the last few days?
Actually, I?ve been saying similar things for years now, Josh, not just the last few days. For example, I noted problems with RPC in[ lots of articles written by him]
[…]
I think my posting pretty clearly implies that Cisco should have avoided writing their own and instead should have reused something that already exists.
[…]
Is everybody really doing [their own rpc system]? Are large commercial distributed systems really built largely on RPC? I?ve seen some non-trivial CORBA-based deployments over the years, but in my experience large systems are built using approaches other than RPC. Like the Web, which isn?t RPC. Like email, which isn?t RPC. Like pub/sub enterprise messaging systems, which aren?t RPC.
Let?s consider the definition of what an RPC actually is. The term is often misused to mean ?a synchronous call to another system over the network.? This is not what an RPC is. For example, an HTTP request is synchronous, but it is not an RPC. RPC, rather, is a specific approach for developing networked applications where local calls wrap and hide operations that happen to be carried out on another system across the network. […]
Next, let?s check RFC 707, where RPC comes from, in which James E. White specifically proposed a procedure call model for networked applications designed to hide the network, and thereby allow developers to use familiar approaches to developing applications that happened to perform network operations. […]
As you can see from the original definition of RPC, something called an RPC that doesn?t hide the network is, by definition, not an RPC. As I said above, unfortunately the term is often misused as meaning ?synchronous messaging,? and that incorrect usage seems to be what Josh is defending. Josh then says:
But then again, I don?t know of any RPC system that tries to hide this from you except possibly CORBA.
That?s not correct either. What CORBA actually does is make everything appear remote, even local objects, but does so in a way that allows object request broker (ORB) implementations to bypass much of the overhead of remote invocations when the ORB knows that a target object is local. Still, not all the overhead can be eliminated due to object lifecycle and method dispatching requirements, meaning that such local calls are typically never as fast as true local calls. DCE also treats services as always being remote, but last I checked it included no local bypass optimizations (though a variant called OODCE once did this, IIRC). But either way, what?s important with these systems is that calls within your code look just like any other calls within your code, whether they?re calling remote operations or not. And that?s RPC.
Regarding versioning problems, Josh says:
But any RPC framework worth its salt makes it possible to have different interface versions interoperate. Adding a new parameter? No problem, old servers simply won?t see it. Completely changing the semantics of your call? No problem ? just give the new call a new name.
Yes, Josh, there are generally ways to do versioning in such systems, but they?re not very good. CORBA includes some facilities to help with versioning, but in practice they don?t actually help that much. Both COM and CORBA promoted interface inheritance and runtime interface negotiation (called ?narrowing? in CORBA) as a way to do versioning, which works, but only for a restricted set of changes. Add a parameter to an existing call? […]
Middleware and distributed systems veterans are well aware of the arguments like the ones I?ve made in my blog and other places recently and in various publications over the years; such arguments are generally common knowledge among us, and have been for years.
Cisco?s system is not available yet, but when it comes out, I?m quite certain you?ll find, Josh, that it?s the same old thing, just repackaged in a new box.
Arquivo Discussoes de Programacao e Tecnologia 
