Web RPCs Considered Harmful

There are two relatively distinct dangers with RPCs used over the Internet, the first is a security issue, the second an open standards issue. There are alternatives that significantly reduce the security and standardization risks, and are just as simple, but they involve application designers using different design patterns than they have become used to, and strongly encouraged by the industry to use, on the desktop and local networks.

Background

The term RPC is used here generically to refer to any application or object interface that is made available over the Internet, regardless of whether it uses remote procedure calls, remote methods, distributed objects, or messaging. Common products and standards that support this are CORBA, DCOM, Java RMI, DCE RPC, XML-RPC, SOAP, and others.

The issues described here only apply to applications implemented on an Internet scale for public use and is not intended to apply to the use of the above products on a local host or network or for proprietary applications, although the alternatives described can be used for those applications also.

CORBA and DCOM are mature architectures for implementing distributed applications using the remote procedure/remote object model (RPCs). Although common and widely adopted on the desktop and local networks, they have not enjoyed broad Internet usage because of slightly heavy installation and usage requirements placed on users. Simpler protocols, like XML-RPC and SOAP, are about to change that and will make RPCs on the Internet as common as HTTP, HTML, and XML. But there is danger lurking here.

These are simple XML based protocols, anyone with an XML parser and a few minutes can be working with a Web-based application in no time. This is generally perceived as a very good thing (and if it weren't for the danger this entails and equally simple, safer alternatives, I would agree). The alternatives discussed below can also be implemented using XML just as easily.

Internet Security

The RPC model encourages numerous unique applications, each with one or more new, unique implementations. While some rigorously developed applications may be thoroughly screened for security holes, the vast majority of applications will never have security as a high priority.

A similar issue exists in Web servers. Web servers themselves are generally very robust pieces of software, but they allow application developers to extend the web server using modules or Common Gateway Interface (CGI) applications. These modules and CGIs also range from quick hacks to robust, rigorously developed applications. Server modules and CGIs are well known for being the weakest point in web server security.

Unique application programming interfaces (APIs) also place an immense burden on users and security analysts who must make assessments of each new API that is allowed to connect to their hosts. This assessment is necessary because Internet security is not just about assessing a protocol, but also the applications and environment using the protocol. Each new API, just like a new protocol to be supported, requires a new assessment.

Lock-in or Fragmentation

Although interfaces can be developed in an open manner, with all parties having equal access and the result supporting all parties, common, and expected, usage of RPC protocols encourages single-source interface definitions.

Single-source interfaces almost invariably favor the originator's implementation, are controlled by the originator, and often are not well-matched to alternative implementations. Additional implementations must either adopt the original interface and be held captive to it (lock-in) or create a new, alternate interface (fragmentation).

Alternatives

One of the core benefits of an RPC standard is that it provides a generic method, with supporting libraries, for communication between applications. Therefore, any alternative must also provide a generic method for communication between applications.

One approach is not to try to change the need or amount of information to be communicated, but to just change the nature of the communication.

The current trend in software development focuses on interfaces as a dividing line between code modules, to reduce interdependancies internal to each module. Popular styles of object oriented development take this one step further and promote primarily the use of interfaces to interact with data or services. These coding styles lend themselves naturally to remote communication, hence the common RPC-style protocols.

An alternative is to focus on data transfer protocols rather than remote API protocols. Data transfer protocols will be relatively few, which leads to well-known, well-tested implementations, and is well suited to open standardization.

Several such protocols already exist (HTTP, TupleSpaces, restricted forms of SQL), so it's not a matter of brand new protocol development but of developing and adopting design patterns that revolve around data transfer protocols.

About the Author

Ken MacLeod is an independent systems consultant with 20 years experience in protocols, open systems, and the Internet. Ken wrote the Perl implementation of XML-RPC and a Perl and Python implementation of SOAP, and is an active participant on the SOAP and XML Distributed Applications mailing lists.

Ongoing discussion of this topic should be directed to the XML Distributed Applications mailing list. The archive is at http://lists.w3.org/Archives/Public/xml-dist-app/, to subscribe, send a message to xml-dist-app-request@w3.org with the subject "subscribe".