RPC framework
Tools enabling the programmers to communicate remotely
04 Nov 2017
View Comments
#rpc
#framework
#remote
#call
#client
#server
 |
RPC calls are probably the most important piece of work that API developers should know. First, we need to know what RPC is. Remote Procedure Call (RPC) is essentially a procedure (providing micro-services) initiated from a computer that executes typically on another server which behaves like the code is executed on your localhost over typically HTTP application-level protocol. “RPC framework” is basically a framework to generate these remote calls conveniently, efficiently, and portable (via different languages) without having to generate these manually with your choices over different transports (Sockets, HTTP, streams, etc), protocols (JSON, binary, compact, etc), and layers (prioritization, efficient compression, etc). There are obviously many great RPC frameworks available out there. I just like to go over the ones I have experienced implementing so far.
SOAP and REST
 |
The SOAP/WSDL and the Restful representation is probably most commonly used method of communication between applications over the World Wide Web (WWW). They are not mutually exclusive. REST can be applied to use SOAP services instead of HTTP (per se). Anyways, there are obviously significant differences between them. SOAP is pretty common even nowadays which defines standard communication rules specified in the XML-based message exchange. WSDL defines the format of XML for the requests/responses. SOAP is usually done in HTTP application protocol which can be utilized in different transport protocols such as SMTP. To implement SOAP services, I would recommend using the “Spring-WS” which in my opinion, provides an intuitive way to create the SOAP web service through annotations and various dependencies. On the other hand, REST is more of a set of principles to follow (concept) than defining a standard message format like SOAP. Remember, SOAP is a protocol where REST is more of an architectural style. Unlike SOAP which is operated in XML, RESTful can be applied with pretty much any formats (plain text, HTML, XML, JSON, even binaries if you need), although JSON is a popular format for REST.
At the end of days, the choices are yours. From my experiences, I’d like to utilize REST when it interacts with a browser (serving like a front-end web application). Utilize SOAP on services that do not necessarily interact with a browser and require strict rules for their use. With the browser, it comes with added benefits such as caching, security, etc.
Apache Thrift
 |
Initially developed by Facebook for “scalable cross-language services”, it is now an open source project in the Apache Software Foundation. When I first used their generated code, I was mesmerized by how the code is utilized conveniently for me to use, which is just based on the Thrift interface definition I created. It was pretty easy to apply generated code to create a server or client. Here is a link where you can take a look at some examples of Thrift in Java. It is fairly well organized and well laid out. One of the strong points of Thrift is that it is available for many languages so functions are run fairly seamlessly between different languages. Another strong point would be how it handles/communicates data between services by utilizing binary serialization to transfer data in a compact form quickly and efficiently.
ZeroC ICE
 |
Internet Communications Engine (ICE) is an open source RPC framework initially developed by ZeroC. ZeroC is supported in various languages like Thrift. However, I personally find it very convenient use for ‘Python’ language. Ice provides a useful function called ‘loadSlice’ where I can load ice objects dynamically. When a program calls the Ice.loadSlice function, the code is generated from Slice definitions dynamically at runtime. Dynamic code generation slightly increases program start-up time but eliminates the need to generate and manage additional Python source files. For C++ or Java, you are stuck with static code generation statically, slice2cpp or slice2java. Python also offers a code generation statically through slice2py. I have not experienced a case where I had to statically load in Python. However, dynamic loading does take longer to generate ice code versus static loading (where the code is already generated). So choose wisely!
Similar to .thrift file for Thrift interface definition (IDL), ICE provides .slice file instead which is a ZeroC-proprietary file format that programmers follow to edit computer-language independent declarations and definitions of classes, interfaces, structures, and enumerations. ZeroC considers the “Slice” as the language and they have a good documentation around it.
GRPC
 |
gRPC is a modern, lightweight RPC framework provided by Google. It enables client and server applications to communicate transparently and makes it easier to build connected systems. gRPC uses HTTP/2 for transport (see demo of http2 vs http/1.1) which utilizes the serialization through the “protocol buffers” (by providing IDLs similar to Thrift or Ice). It provides some key features as bidirectional streaming, flow-control, blocking or nonblocking bindings, which allows you to build services with both synchronous and asynchronous communication model. Fundamentally, Protocol Buffers serves message interchange format, as well as describing the service interfaces (service endpoints) then we have added RPC features which together builds the RPC framework of gRPC.
