%0 Generic %1 vinoski09qcon %A Vinoski, Steve %C London %D 2009 %K evolution history rpc %T RPC and its Offspring: Convenient, Yet Fundamentally Flawed %U http://qconlondon.com/london-2009/presentation/RPC+and+its+Offspring%3A+Convenient%2C+Yet+Fundamentally+Flawed %X In 1976, RFC 707 described the "Procedure Call Model" as a way to make remote resources as easy to use as local ones, with the goal of helping application programmers of the day get over their lack of proficiency with network programming. It proposed that the procedure call was the right abstraction for extending the local programming environment to provide familiar access to modules and libraries hosted on remote systems. From this idea came the Remote Procedure Call (RPC) and all its derivatives, including DCE, distributed object systems like DCOM and CORBA, XML-RPC, and SOAP-based web services. A fundamental goal of these and countless other similar technologies developed over the years was to shoehorn distributed systems programming into the local programming models so customary and convenient to the average developer, thereby hiding the difficult issues associated with distribution such as partial failure, availability and location issues, and consistency and synchronization problems. We've known for a long time about fundamental problems with RPC-oriented approaches, yet over the past three decades we've largely ignored those issues and invested incalculable amounts of time and money on developing and using software systems that try to make distributed systems appear local. This talk will present a history of RPC, discuss reasons why the RPC model has been so persistent despite its fundamental flaws, and suggest alternatives that are both convenient and correct.

@misc{vinoski09qcon, abstract = {In 1976, RFC 707 described the "Procedure Call Model" as a way to make remote resources as easy to use as local ones, with the goal of helping application programmers of the day get over their lack of proficiency with network programming. It proposed that the procedure call was the right abstraction for extending the local programming environment to provide familiar access to modules and libraries hosted on remote systems. From this idea came the Remote Procedure Call (RPC) and all its derivatives, including DCE, distributed object systems like DCOM and CORBA, XML-RPC, and SOAP-based web services. A fundamental goal of these and countless other similar technologies developed over the years was to shoehorn distributed systems programming into the local programming models so customary and convenient to the average developer, thereby hiding the difficult issues associated with distribution such as partial failure, availability and location issues, and consistency and synchronization problems. We've known for a long time about fundamental problems with RPC-oriented approaches, yet over the past three decades we've largely ignored those issues and invested incalculable amounts of time and money on developing and using software systems that try to make distributed systems appear local. This talk will present a history of RPC, discuss reasons why the RPC model has been so persistent despite its fundamental flaws, and suggest alternatives that are both convenient and correct.}, added-at = {2009-03-18T21:16:31.000+0100}, address = {London}, author = {Vinoski, Steve}, biburl = {https://www.bibsonomy.org/bibtex/2467faf06b11b06d04fa980844f2e7bb1/neilernst}, interhash = {dc02060662c5151839ca7c1f9d2d0e15}, intrahash = {467faf06b11b06d04fa980844f2e7bb1}, keywords = {evolution history rpc}, month = {March}, note = {QCon }, timestamp = {2009-03-18T21:16:31.000+0100}, title = {RPC and its Offspring: Convenient, Yet Fundamentally Flawed}, url = {http://qconlondon.com/london-2009/presentation/RPC+and+its+Offspring%3A+Convenient%2C+Yet+Fundamentally+Flawed}, year = 2009 }