In the winter of 1974, Internet guru Jon Postel published RFC674: “Procedure Call Protocol Documents, Version 2,” an attempt to define a common way to share resources across a network of 70 nodes. Of the countless RFC documents edited by the master during his lifetime, 674 was one that did not stand out, but it was the beginning of RPC. And that’s where the rest of our story begins.

1. From IPC to RPC

Inter-process Communication (IPC) refers to inter-process Communication. Communication between different processes. There are many types of IPC in the Unix family, but one in particular needs attention — sockets. Unlike other IPC types that only support interprocess communication on the same machine, sockets are widely used for remote communication between different machines.

Fast-forward to the 1980s, when Bill Joy casually told a DARPA official, “I just read the protocol, type the code, and write it.” Berkeley sockets were doomed to be different. Socket was introduced in BSD 4.2, the implementation of TCP, by which time Bill Joy had co-founded SUN. Berkeley sockets are not only the basis of TCP/IP communication for Unix operating systems, but also the cornerstone of communication in the entire network world today. Even Windows sockets are derived from this.

Remote Procedure Call (RPC) refers to Remote Procedure Call. RPC is a technical idea, not a specification. In fact, with the passage of time and technological evolution, it has become more and more difficult to define what RPC is. But back in the ’80s and’ 90s, basically, I was calling a function locally, or a method on an object, actually calling a function on a remote machine, or a method on a remote object, but that communication was transparent to the programmer, to a degree of location transparency. It sounds like a good idea for business logic programmers like us, but there are also opponents who believe that the transparency of communication can increase the cost of communication by giving programmers the illusion that communication is cost-free.

Of course, the RPC concept itself applies to transport layer protocols other than TCP, but the one we use most is TCP/IP.

All you need is a Wire Protocol and a Name Service to customize the simplest RPC library. Socket communication, as well as serialization and deserialization, are encapsulated within the RPC framework and do not require manual programmer handling. Of course, a mature RPC library is not so simple, it contains more functions to be responsible for, the problem to be solved more difficult.

Note: Wire Protocol is not a network Protocol, but a data serialization and deserialization rules.

From the mid 1970s to the end of 1980s, papers on RPC emerged one after another. There’s support, there’s skepticism, there’s fanaticism, there’s criticism. And so it went into the next decade.

2. The Three Kingdoms Era of RPC middleware

At the beginning of the last decade of the last century, object orientation was in the air and the Internet had not yet exploded, but that did not prevent the development of enterprise-scale networks. Distributed system has emerged, communication is an eternal topic.

In those days, communication and collaboration between different hardware, OS, and programming languages was a nightmare. In 1991, CORBA came out of nowhere. CORBA stands for Common Object Request Broker Architecture. It is a standard issued by the OMG (Open Manage Group) organization and epochal proposed Distributed Object technology. Since then, RPC has evolved object-oriented semantics from procedural semantics. Although version 1.0 of CORBA only supported C mapping, it did offer new hope for interoperability between heterogeneous environments.

A lot happened in 1991. This was the year the first Python compiler was created. At the time, a group at SUN was attacking the Oak programming language. The World Wide Web made its debut in May when Tim Berners-Lee released the first HTTP version, HTTP/0.9. "Hello Everybody out there using minix -- I'm doing a (free) operating system," a Finnish guy posted on a BBS in August.Copy the code

Without further ado, CORBA uses the ORB component, the middle three letters of CORBA, to handle communication. This component is a request broker where the client code simply sends a request to the client ORB, which locates the server ORB, and automatically handles the connection and transfer data. So how do you transfer “objects” between two OrBs? The answer is GIOP (General Inter ORB Protocol), which specifies rules for serialization and messaging of objects. GIOP is known for being short and flexible, but is itself an abstract protocol. Internet Inter-ORB Protocol (IIOP) is the specific implementation of GIOP on IP Protocol. IIOP is a Wire Protocol.

In addition, CORBA uses IDL (Interface Description Language) to describe interfaces, shielding the differences between different programming languages. By using compilation tools, IDL files can be compiled into client stub code and server skeleton code of multiple languages, and stub and skeleton can be different programming languages. When a remote method is invoked, the stub code sends a request to the ORB.

In addition to the basic RPC function, there are transaction management, concurrency control and other functions, because of further freeing programmer’s hands, make it focus on business logic, so the technology architecture represented by CORBA is also called – RPC Middleware.

In 1993, Mosaic, the world’s first modern browser, opened the door to a new era.

The future of Java didn’t begin there, though applets may have been a bit of a thing of the past since Oak was upgraded and renamed Java in 1995. This was followed by RMI, a Java platform-based RPC technology (later by RMI-IIOP, which allowed RMI to communicate with CORBA systems), and later by Javabeans. Until 1998, when SUN released JDK1.2, ejbs were born, and the world exclaimed, “done.” Java has its own distributed object solution. Since then, Java has been able to compete with COBRA and DCOM to dominate the world.

In the same year, CORBA added the mapping to the Java language. In the second year, CORBA3.0 standard came out, which proposed the third Component Model CCM (CORBA Component Model) that is not used for DCOM and EJB. In addition, it supports more mapping languages, not only C/C++, Java, Smalltalk, Ada, COBOL are also supported. But in the end it was too late. The experts who wrote the CORBA specification were largely out of touch and the CORBA specification was obscure. Theory from practice, can not help but think of OSI/ISO and TCP/IP story, let a person sigh unceasingly. In addition, manufacturers in the implementation process can not fully understand and comply with the specification, each has their own interpretation, and finally lead to incompatible. There are other issues, such as the wide variety of programming paradigms due to different language type systems. It is therefore very difficult to abstract IDL syntax as an intermediate language suitable for compiling into various language interfaces, but history is full of attempts to do so again and again, but that is another story.

Java language itself cross-platform, Java RMI focuses on a single language solution that is simple to write. There is no need for CORBA to introduce IDL for various languages. The history is so interesting that CORBA technology was proposed to adapt to the heterogeneous network environment and different programming languages because of the complexity of implementation. The single-language JavaEE solution, on the other hand, gained support for its simplicity, which in turn contributed to the Java language’s popularity. It’s hard to predict what will happen. It can only be said that in different times, people have different choices.

3. RPC fable: The Circle of ten years

It has been more than forty years since the 1974 paper published the thought of RPC. During this period, RPC was not smooth sailing, and criticism was also heard.

In 1987, Professor Tanenbaum published “A Critique of the Remote Procedure Call Paradigm” saying that treating local calls as if they were Remote calls is A mistake. Moreover, it is impossible to achieve complete transparency of communication, and once the communication of a system is partially transparent, it will increase the complexity of the programmer’s work.

In 1994, Jim Waldo (et al. 4), then A senior researcher of SUN Corporation, published A famous paper “A Note on Distributed Computing”, which bitterly described the four crimes of RPC:

  1. Communication time delay
  2. Address space isolation
  3. Partial failure
  4. Concurrency issues

Of course, most crimes are inherent in distributed systems. Interestingly, Waldo had a ten-year theory:

Every decade people try to unify local and remote computing, again and again.
However, local computing is quite different from remote computing.

Ten years is definitely an imaginary number, but it’s worth thinking about, to some extent, suggesting the periodicity of RPC. Jim Waldo seems to be a critic of RPC, but he has contributed greatly to the development of RPC technology. Prior to Sun, Waldo led the design and development of the first ORB at HP, leading to ORB’s inclusion in the first version of the OMG CORBA specification. Later, when working in SUN Company, I also led and participated in the design and development of a number of RPC related technologies.

Go back to the previous timeline.

In 1998, XML 1.0 was released and became a W3C recommendation. Since then, XML has risen rapidly as the industry’s new darling. “Whatever is described in XML is good and whatever doesn’t use XML is garbage.” XmL-RPC was born under two general guidelines, but its successor, SOAP, soon emerged. Don’t call him the soap protocol.

Web Service (WS) uses the SOAP protocol as the serialization standard for RPC. SOAP is described by XML, or is itself a subset of XML. SOAP is a Wire Protocol whose delivery still depends on a “medium”, which can be HTTP, TCP, or even JMS. There is also a WSDL in WS, similar to THE IDL in CORBA, that describes the WS interface and can be compiled into stub code with tools. WSDL is also described in XML. With WS, engineering practices based on SOA architectural ideas can be easily accomplished.

At the beginning of the century, Microsoft saw the bleak future of DCOM and pushed WS. At that time, Microsoft and IBM were strong backers of WS. Although WS can also be applied to inter-system communication and service-oriented solutions within enterprises, it is mostly used in the access layer (HTTP). Later, WITH the rise of API technology represented by REST style, WS gradually disappeared, which also marks the complete defeat of RPC technology in the access layer.

4. Temple and Lakes: Modern RPC

Two thousand years later, in the midst of the Internet bubble, a single MVC architecture style was enough for many smes. Many people have forgotten the existence of RPC, is it true that the decade cycle? The answer is no. In fact, RPC has never disappeared, it is in large enterprises, RPC technology has been developing rapidly, especially after the outbreak of mobile Internet, the background bottleneck is increasingly prominent, RPC once again from behind the stage to the front. RPC middleware exploded at a time when modern RPC frameworks had incorporated SOA architectural ideas, as well as other technologies. While RPC remained the foundation of middleware, additional technologies later became more dominant and more representative of a middleware. RPC is less prominent (though still important) in comparison.

In 2008, Google opened source Protocol Buffer (ABBREVIATED as PB). PB is not only compatible with all kinds of programming languages, but also far more efficient than XML and JSON because it is a binary Protocol. After open source, it quickly swept the world. In the same year, Facebook officially open-source Thrift to Apache, which provides a variety of serialization options, including binary ones. In addition, although PB is excellent, it is only a serialization library and an efficient Wire Protocol, while Thirft is a relatively complete solution that provides several ready-made servers in addition to the basic functions of RPC. Also Thrift contains an IDL that is compatible with common programming languages.

In 2015, Google open source gRPC framework, once released, quickly gained wide attention, there is no doubt that gRPC uses PB as a serialization solution, and the creative use of HTTP/2 in the transmission medium. In addition, gRPC supports bidrectional Streaming communication, and RPC framework is no longer confined to the constant C/S model, so gRPC can build services (SOA or Microservice) more easily and quickly. And that’s the downside of Thrift.

Of course, enterprise open source projects need to be modified and adjusted to release, not directly take the internal code of the enterprise open source. So although gRPC has been running inside Google for years, the open source version of gRPC is still relatively immature, and Thrift has been in the works for a decade since it was opened in 2007. But FOR the foreseeable future, I believe gRPC and Thrift will be the two most visible poles of open source RPC frameworks.

Today, we can see that more and more cutting-edge technologies are now controlled by industry giants and the open source community. In fact, IT is not a zero-sum game in the field of IT.

We often say that “the economic base determines the superstructure.” In the area of back-end technology, it is not the economy that determines our superstructure. It is these RPC frameworks. By using these mature RPC frameworks, we were able to think in a higher dimension. Thanks to these businesses and all contributors to the open source community.

You think that’s where the story ends?

After CORBA’s demise, a group of OMG practitioners left and founded ZeroC in 2002 to develop the ICE framework, not to revive CORBA, which is known as the ICE of Rebellion. Doug Cutting, the father of Hadoop, was unhappy with the moderation of Thrift’s design philosophy and started building more wheels, hence Avro. Looking at China, in 2011, the open source giant Ali also opened from the development of RPC framework – Dubbo. However, in recent years, it has been heard that it has shifted to a new generation of Framework — HSF (High Speed Framework). In 2014, Facebook again open-source the lightweight Thrift framework — FbThrift…

RPC, middleware, services, this arena is not covered in many stories, and new stories continue. Call it bad RPC, call it red RPC. Say “fried rice” or “take the essence, discard the dregs”. Our environment is constantly changing, and so are the problems we face. RPC is certainly not a silver bullet and may indeed be Mired in a decadal cycle, but we are certainly not Sisyphus.

Technology will become obsolete, and the later waves will overtake the former. Predecessors in the road of technology exploration, perhaps we have long forgotten. But I believe that those shining names are all in light. And today’s technology is all brilliant, are standing on the shoulders of giants.

Resources & Recommended reading

  • RPC
  • RPC is Not Dead: Rise, Fall and the Rise of Remote Procedure Calls
  • CORBA, the rise and fall of
  • Introduction of CORBA
  • Comparison between CORBA and RPC
  • CORBA GIOP message format learning
  • GRPC website
  • Apache Thrift website
  • fbthrift github
  • Finagle website
  • Dubbo website
  • A Critique of the Remote Procedure Call Paradigm
  • A Note on Distributed Computing