PEPtAMinimalRPCArchitecture.pdfVIP

PEPt A Minimal RPC Architecture Harold Carr Sun Microsystems, 4140 Network Circle, SCA14, Santa Clara, CA 95054 U.S.A. harold.carr@ Abstract. We present a high-level RPC architecture. Although RPC systems seem quite varied they actually share the same fundamental building blocks. We examine the operation of several technologies (e.g., SOAP/HTTP, RMI- IIOP) to show what they have in common, namely four main blocks that we call PEPt: Presentation, Encoding, Protocol and transport. Presentation en- compasses the data types and APIs available to a programmer. Encoding de- scribes the representation of those data types on the wire. Protocol frames the encoded data to denote the intent of the message. Transport moves the encod- ing + protocol from one location to another. The PEPt architecture allows one to understand, use and implement RPC-systems by providing a simple but comprehensive framework in which to place finer-grained details. It may also serve as the basis for RPC infrastructure reuse between seemingly disparate systems. The PEPt architecture enables an RPC system to adaptively change encodings, protocols and transports. 1 Introduction The specification and implementation of Remote Procedure Call (RPC) [1] systems such as DCE [2], distributed versions of C++ [3][4], COM/DCOM [5], CORBA [6], RMI [7], RMI-IIOP [8], XML-RPC [9] and SOAP [10], seems to traverse the same ground repeatedly. One way to avoid reinventing the wheel is to isolate the basic building blocks. This may seem difficult since, at first glance, it may seem RPC systems have nothing in common. We claim that these systems