So I talked, well actually chatted via instant-messaging, with Steve Vinoski and I do need to clear up some points from my last blog entry.
Steve pointed out that RPC does NOT require synchronous communications. This is true. One can simulate the request-response of a remote procedure using asynchronous communications. But the idea is that RPC appear synchronous - like a programming language procedure that blocks.
Some synchronous technology can appear asynchronous. E.g. CORBA has oneway operations. And many queue based (messaging) technologies use connection based technology underneath. E.g. Some publish subscribe technologies are actually connection based. The publisher connects to the notification service and so does the subscriber when retrieving messages. They are asynchronous to the application in the sense that they are decoupled.
Back to the Steve conversation. Steve maintained that RPC basically implied location transparency. I'm not sure I agree. Though many RPC technologies have location transparency I don't think that that the orginal intent for RPC was that it have location transparency. I certainly regard come technologies today as RPC that don't have location transparency. RFC 707 doesn't mention location transparency and as it works through command/response, request/reply and procedure call models it speaks of making it easier but I don't see transparent. In fact in order not to "mislead the application programmer" the paper suggests the model be clarified with "Local procedure calls are cheap; remote procedure calls are not."
Location transparency is very often a bad thing. (more often than not as we discovered with novice developers of CORBA and distributed Java technologies and many more.) Because location transparency hides the network, this can mislead the developer and also introduces issues of extra exception handling that the developer has make sure that they cover. Steve wrote an excellent paper on some of the issues in IEEE's Internet Computing back in late 2005 - I have a copy but I don't have a public URL for it, sorry.
But one could argue this both ways. i.e. The technology is not good because it misleads the programmer OR you could say that one needs better than average programmers to develop distributed application architectures using RPC. But it seems that one could say the same thing about RESTful developers. So before we accept the former (the technology is not good) let us remember that not all REST developers are building truly RESTful based applications/services. In fact RESTful Web services points out that most REST based services are REST-RPC and not RESTful.
Again, I wish to point out that I continue to warm to REST and Resource Oriented Architectures, I see the potential, and look forward to implementing. I'm just not willing to say that REST is useful in all situations or that SOAP and WS-* are evil and there is no place for them. And, as the book points out, there is still a lot of confusion with REST based on the wide deployment of REST-RPC services rather than RESTful.
The book has this to say about breaking the uniform interface: "occasionally it's unavoidable" (p101). Even while it's undesirable. The section on POST describes this scenario. And so some "overloading" is required. Does this mean then that REST is broken? Or should the REST community loosen the definition of RESTful? Is "reshuffling" the resources acceptable, or a hack that demonstrates something that needs to be addressed with the model?
IP Babble is the personal blog of William Henry.
Leave a comment